October 26, 2006
Modeling Unit Tests in UMLIf you like to practice test-driven development, but want to use it not just at your desk when you're coding, but also at the white board when you're modeling, then here's a simple technique you can use.
A unit test has three basic components:
1. A start state - the objects, their attribute values and relationships with each other before the method you're testing is called
2. An action - the method call (or sequence of calls) you are testing
c. An end state - the objects, attribute values and relationships after the method you're testing has executed
In code, we set up our test objects to create the start state, we call the method that we're testing and then we make test assertions about the end state.
We can just as easily model this using a cool technique from the Catalysis method kown as filmstrips. A filmstrip is a pair of object diagrams ("snapshots") that model the before (pre-condition) and after (post-condition) of an action or sequence of actions. It's pretty much exactly the same information we find in a unit test, only in UML: which means we can draw our unit tests on the white board and have meaningful and productive discussions about them.
In this example filmstrip, I'm modeling a unit test for the borrow() method on a Video object (called Jaws for the purposes of illustration). Pay particular attention to the emboldened parts of the post snapshot. These make it easier to spot what has changed as a result of the borrow() method being called. It also helps to enumerate these differences, so we can see exactly what that method call has achieved:
1. An instance of class Loan was created called loan
2. The date attribute of loan was set to today's date
3. A link was created between loan and Jason, and loan has been inserted into 0..* role loans
4. Another link was created between loan and Jaws
5. The onloan attribute of Jaws was set to true
Those look a lot like test assertions to me. If I was writing the actual unit test code, I would expect to make an assertion for each of these differences. The Java code might look a little like this:
Posted 14 years, 9 months ago on October 26, 2006