Test driven development with BPMs


I have read a book about Test Driven Development written by Kent Beck. This is a very famous and good book about test driven development with Java. This technique can also be adapted when developing a Service Oriented Architecture or implementing BPMs. For example with Cordys. This blog describes some guidelines.

Some Guidelines

  1. Be sure to write your BPMs with as less context as possible
    This means that the context should be given as a parameter for example. In this case you can use soapUI or SOATester to test the BPM independently of the other BPMs.
  2. Each time there is an error within the BPM, be sure to write a test case for the error that shows the error
    After that solve the error and this way the test set also becomes bigger.
  3. Just like with the technique described within the book, you can start with writing the soapUI scripts first and then implement the BPMs
    This way your test cases should represent the exact requirements for the BPMs.
These are just some guidelines which are easy in theory but of course always hard in practice. But the message is also that you should consider the test fullness of your BPMs and Services. Only this way you can refactor your architecture with confidence. It also emphasizes that testing must be considered as soon as possible within your programs.

Please feel free to react and ask questions.

For completeness i have added a link to the book:   


Some common BPM mistakes

In a lot of projects i have done for customers there are a few misunderstandings i often see with BPM or Business Process Management.

 1) You are not doing BPM when using a BPM tool
It is often called already BPM because it is hot, but the business is not process oriented at all. This is because a BPM tool is introduced bottom up, but the organization is not process oriented at all. In fact the business is process oriented (by default there is of course always a process), but this is not analysed or controlled.

 2) Flexibility comes not for free
This is maybe in theory but in practice i have rarely seen this. Making a solution flexible requires a lot of future knowledge which is often very difficult of course. You can only make your BPM solutions flexible where you know you need the flexibility.

 3) BPM does not solve it all
As with all new hypes, this is the next magic tool that solves it all. Of course this is not the case and it requires a lot of good thinking and experience to implement a BPM solution. In fact it may be far more difficult because it often expands more business units within the organization.

4) BPM(N) is not a new programming tool
Within a BPM solution there exists a BPMN drawing toolbox. With this tool you should model the business process on certain levels. What i often also see is that Services are also implemented with this tool. However it may be better practice to implement the Service within Java or another platform.

5) Testing BPMs is not something you do afterwards
Testing is often a underestimated effort. I personally think that 1 developer needs 1-3 testers.

And there are probably a lot more ...

Please feel free to react and add more when you like.