StagingSuppose your team is developing a feature (or a user story, or a use case, and so on). This feature would likely be realized by a collaboration of a few classes, let's say A, B, and C and each of these classes are handled by different team members. Each team member would likely write unit tests for their respective classes and then conduct an integration of these classes.
So, for each test scenario (such as A calls B and B calls C), you would need to write the following tests:
Test A with a mock of B (i.e. unit test)
Test B with a mock of C
Test A and B with Mock of C (i.e. partial integration test)
Test A, B, and C together (i.e. integration test)
As you can see, there are many combinations and certainly much potential duplication of testing code and effort if you were to write JUnit tests for each of them. So, we need a better way.
That is why I wrote jSupervisor. jSupervisor uses Java's dynamic proxy mechanism to specify scenarios, record scenarios, and execute scenarios with various combinations of test targets (i.e. the A, B and C we are testing.). With jSupervisor, you can define scenarios in two ways:
specifying the invocation sequence in your JUnit test.
recording invocation from an actual run of the test targets.
During execution, you can define the combination of test targets you want. jSupervisor then plays the execution and compares the actual result with the specified or recorded sequence. There is no need to write mocks as they can be automatically inferred from the test scenario. Basically, if a class is not attached, its invocation would naturally be a mock.
Now, with jSupervisor, you can do test driven development at the feature (or a user story, or a use case) level.
You describe the acceptance test as a scenario (in code, e.g. JUnit). # You execute the scenario without any test targets.
You allocate the implementation of the test targets to various team members.
Each team member execute the scenario on the target he/she is responsible for. There is no need to write any mocks or any other test code.
Each member implements the target code until the scenario is accepted for his/her target.
You test the integration of the target by just attaching the actual target to the scenario.
You continue the integration until the scenario is accepted for all targets.
So, you are writing only ONE test, but the same test can be executed by different team members developing their own part of the system. This is what I call, "Write Once, Test Everywhere."
A key design goal when I wrote jSupervisor is to ensure that scenarios can be written by testers who do not have such strong knowledge of programming compared to developers. So, scenario descriptions must be simple in jSupervisor.
In addition, there must be facilities to pin-point where testing errors occur quickly. This is achieved through a novel watching feature to quickly pin-point where testing errors occur by displaying file and line numbers understandable by the eclipse console parser. This also helps developers debug the scenario execution quickly.
More details here