6 Replies Latest reply on Dec 10, 2008 6:13 AM by kukeltje

    Test Driven Process Development conveniences

    kukeltje

      More and more, I'm becomming a fan of this. But my tests quickly become unreadable by anyone that is not kind of familiar with some jBPM internals/api things.

      I therefore started to create more and more convenience methods in an class that extended AbstractDBTestcase. Things like deploying processes (to prevent things Bernd ran into), testing if tasks exist, are assigned to a specific actor, a specific number of tasks exist etc... all in the context of a processinstance.

      Things I came up with until now are

      For each method in the class under test:
      - Deploy a processdefinition that has the same filename and name as the method itself
      - If not exists deploy a process that has the same filename and name as the class under test
      - Start an instance of it and make sure it is running and usable
      - At the end, clean up all the 'leftovers'

      When working with a processinstance I have the following assertion methods:
      - assertTaskExists(String taskname)
      - assertTaskExistsForActor(String taskname, String expectedActorId)
      - assertTaskListLength(int expectedTasklistLength)
      - assertTaskHasEnded(String taskname)
      - assertProcessHasEnded()
      - assertVariableValue(String variableName, Object expectedValue)
      - assertNodeActive(String nodeName)

      To prevent the need to use more low level jBPM classes, I choose to use strings. Methods that do use them could ofcourse be introduced as well.

      Additional convenience methods that might be in the api eventually are:
      - endTask(String taskName);
      - endTask(String taskName, String transition);
      - assignTask(String taskName, String actorId);
      - unassignTask(String taskName); // same as assignTask with actorId being null or empty string
      - setVariable(String variableName, Object variableValue)


      More methods could be added, but these are the ones I encountered most. I'm currently cleaning up my class before posting it on my blog but hope to get some feedback in advance about this. I also want to add it to the jBPM codebase since it makes tests a lot more easier to read.

        • 1. Re: Test Driven Process Development conveniences
          jbarrez

          Ronald,

          I've created a similar super class for all my test cases.
          I've come to the same methods (and some more) as you mention.

          I'm also writing a blog post about it (in my backlog for a month now .... geez).

          Currently, my test class uses some nifty Spring features for automatic rollback after each test etc... Perhaps we can work together on this to create a general solution?

          • 2. Re: Test Driven Process Development conveniences
            tom.baeyens

            in jbpm4, there is a module test-base. that contains the test classes that users will be able to leverage. they will be packaged in the jbpm.jar.

            please have a look at DbTestCase. that one should be the one that users will be using.

            it's scheduled for the next release: https://jira.jboss.org/jira/browse/JBPM-1907

            • 3. Re: Test Driven Process Development conveniences
              kukeltje

              Sure... why not.... But Sping is not my cup of tea (never needed it, or never saw when it was really handy, or....). The thing is that I do not want to introduce a dependency on Spring in jBPM 3.

              My article also touches on how to posts tests to the forum instead of code snippets, so there were two reasons for writing this. So do you want to post two different articles and refer to a joint effort to create this general solution.

              • 4. Re: Test Driven Process Development conveniences
                kukeltje

                Tom, thanks. I'll try to leverage that as much as possible, change my class and try to backport the jbpm 4 testclass to jbpm 3

                • 5. Re: Test Driven Process Development conveniences
                  jbarrez

                  Ronald,

                  I certainly don't want to introduce a dependency on Spring! I want to 'de-Springify' my test class. If a general solution is found, I can still wrap it up in some Spring bean if needed.

                  I was rather thinking at comparing our solutions and see if we can make something general and more robust out of it. I think your article about 'how to write tests' should come after the explanation of the test case (it'll be a long post otherwise ;-)

                  Tonight, I'm going to take a look at what Tom has provided and see if it fits what I've implemented.

                  Ronald: Tomorrow I'll be at Devoxx, I'll try to wrap something up before the weekend and mail you the results.

                  • 6. Re: Test Driven Process Development conveniences
                    kukeltje

                    Devoxx not for me this year.... (again not :-( ) Wrapping up the work in my house so it is finally finished after a couple of months.