Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-7573

Test org.camunda.bpm.engine.test.mock.Mocks

    Details

    • Type: Task
    • Status: Closed
    • Priority: L3 - Default
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 7.7.0, 7.7.0-alpha2
    • Component/s: engine
    • Labels:
      None

      Description

      This class is API, but not tested.

      Write unit tests and documentation.

      Hint
      See usage in consulting repository https://github.com/camunda/camunda-consulting/blob/master/snippets/uel-variable-evaluator/src/test/java/com/camunda/bpm/demo/uel_variable_evaluator/nonarquillian/InMemoryH2Test.java

      This repository contains other examples too.

        Issue Links

          Activity

          Hide
          meyer Daniel Meyer added a comment - - edited

          Smirnov Roman this is probably a good topic for Tassilo. Bernd Rücker will provide some more input.

          Show
          meyer Daniel Meyer added a comment - - edited Smirnov Roman this is probably a good topic for Tassilo. Bernd Rücker will provide some more input.
          Hide
          ruecker Bernd Rücker added a comment - - edited

          We use the Mocks class very often to register named bean instances on the process engine to be used within Expressions.

          E.g.:

          Mocks.register("myBean", new ByBean());
          

          allows to write

          #{myBean.someMethod()}
          

          Without having Spring, CDI or other bean managers in place.

          Typical Use Cases:

          • Test cases & Mocking (that gave it the name originally).
          • Easy applications without Spring or CDI (e.g. if you use .NET but want to have simple engine plugins).

          So my proposal is to extend the scope of this issue slightly:

          1. add the MocksExpressionManager to every ProcessEngineConfiguration by default (currently you have to do this yourself). It does not do any harm if there! Then you can just start registrering own beans.
          2. Test it
          3. Document it properly in the user guide for the different use cases (especially testing)

          Show
          ruecker Bernd Rücker added a comment - - edited We use the Mocks class very often to register named bean instances on the process engine to be used within Expressions. E.g.: Mocks.register( "myBean" , new ByBean()); allows to write #{myBean.someMethod()} Without having Spring, CDI or other bean managers in place. Typical Use Cases: Test cases & Mocking (that gave it the name originally). Easy applications without Spring or CDI (e.g. if you use .NET but want to have simple engine plugins). So my proposal is to extend the scope of this issue slightly: 1. add the MocksExpressionManager to every ProcessEngineConfiguration by default (currently you have to do this yourself). It does not do any harm if there! Then you can just start registrering own beans. 2. Test it 3. Document it properly in the user guide for the different use cases (especially testing)
          Hide
          thorben.lindhauer Thorben Lindhauer added a comment - - edited

          Hi Bernd Rücker,

          Not sure I understand this point:

          Easy applications without Spring or CDI (e.g. if you use .NET but want to have simple engine plugins).

          Is it actually possible to build applications using the Mocks class? The class is based on a thread-local hashmap. That means, an arbitrary job executor or HTTP server thread would not be able to access a mock unless I register it before in that thread's context, which is hardly doable. Or am I missing something?

          Show
          thorben.lindhauer Thorben Lindhauer added a comment - - edited Hi Bernd Rücker , Not sure I understand this point: Easy applications without Spring or CDI (e.g. if you use .NET but want to have simple engine plugins). Is it actually possible to build applications using the Mocks class? The class is based on a thread-local hashmap. That means, an arbitrary job executor or HTTP server thread would not be able to access a mock unless I register it before in that thread's context, which is hardly doable. Or am I missing something?
          Hide
          thorben.lindhauer Thorben Lindhauer added a comment -

          There is also the engine configuration property beans, a Map<Object,Object> which is used in EL expressions, etc. Is that what you have in mind for this use case?

          Show
          thorben.lindhauer Thorben Lindhauer added a comment - There is also the engine configuration property beans , a Map<Object,Object> which is used in EL expressions, etc. Is that what you have in mind for this use case?
          Hide
          ruecker Bernd Rücker added a comment - - edited

          Hi Thorben.

          Damn it - the Mocks using a ThreadLocal? I forgot that - then it is not usable for the use case I had in mind either. And I was sure I used it for this some times already - but it rings a bell - I might have done it differently in the end.

          So something like a beans Map in the ProcessEngineConfiguration might be the better way to go. Lat time I tried it was not usable in a way, that I can just set java instances programatically somewhere in e.g. a ProcessEnginePlugin. I think it only worked when used within a Spring context to wire some spring beans. But forgot the exact problem there. But pimping that to make it usable for the use case I dscribed would be fantastic - but thats a different isssue - so we might move it out of this context.

          Sorry!
          Cheers
          Bernd

          Show
          ruecker Bernd Rücker added a comment - - edited Hi Thorben. Damn it - the Mocks using a ThreadLocal? I forgot that - then it is not usable for the use case I had in mind either. And I was sure I used it for this some times already - but it rings a bell - I might have done it differently in the end. So something like a beans Map in the ProcessEngineConfiguration might be the better way to go. Lat time I tried it was not usable in a way, that I can just set java instances programatically somewhere in e.g. a ProcessEnginePlugin. I think it only worked when used within a Spring context to wire some spring beans. But forgot the exact problem there. But pimping that to make it usable for the use case I dscribed would be fantastic - but thats a different isssue - so we might move it out of this context. Sorry! Cheers Bernd
          Hide
          thorben.lindhauer Thorben Lindhauer added a comment -

          Hi Bernd,

          Thanks for your response. We were wondering during the review

          Cheers,
          Thorben

          Show
          thorben.lindhauer Thorben Lindhauer added a comment - Hi Bernd, Thanks for your response. We were wondering during the review Cheers, Thorben

            People

            • Assignee:
              thorben.lindhauer Thorben Lindhauer
              Reporter:
              thorben.lindhauer Thorben Lindhauer
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development