Intent Keep the system in sync with the business rules it implements by encoding the rules explicitly as tests.
How do you keep the actual business rules, the documentation about those business rules and the system implementation in sync, while all three are changing?
This problem is difficult because:
Written documentation gets out of date quickly and does not ensure you that your system really implements the description of the business rules you have.
Business rules tend to be implicit in the code. It may not be obvious which pieces of software are responsible for computing a given business rule.
Developer turn-over introduces a high risk for your business by having more and more people knowing less and less about the system.
Most of the time only one programmer or user knows specific rules, and that person could be leaving tomorrow.
Business rules are likely to change due to external factors, such as the introduction of a new law, so it is important to represent them explicitly.
Yet, solving this problem is feasible because:
- Most business rules are well expressed by sets of canonical examples, each of which requires certain well-defined actions to be taken, and results in some clear, observable results.
Write executable tests that record the business rules as test cases, actions, and tests over the results. When tests break, you know that things are out of sync.
Developers and clients can write tests. Developers may write tests associated with specific functionality or piece of code. User may also have to write integration tests in the form of use cases that bind together several unit tests [Dav95] [Bec00].
Note that you are not interested in the implementation strategies or optimization aspects, but only the business rules.
The rules become explicit, thereby reducing dependency on human memory.
You need to record the business rules anyway before you can reengineer the legacy system.
Recording business rules as tests enables evolution: when new features must be added, you can check that the existing business rules are still correctly implemented by running the regression tests. On the other hand, when the business rules change, you can update the corresponding tests to reflect the changes.
Tests can only encode concrete scenarios, not actual the logic of the business rules themselves.
When the business logic must deal with an extremely large number of cases, it may be impractical to test them all.
Recording business rules does not mean extracting them. Extracting business rules from code with the current technology is a pipe dream.
Recording business rules can be difficult for system whose original developers and users have all left.
In this example we compute the amount of additional money an employee receives for a child. The rule states that a person or couple gets an amount of money for every child he, she or they raise. Basically parents get CHF 150 per month for every child younger than 12 years, and CHF 180 for every child between 12 and 18 and for every child between 18 and 25 as long as the child is not working and is still in the educational system. A single parent gets the full 100% of this money as long as he or she is working more than 50%. Couples get a percentage of the money that is equal to the summed working percentages of both partners.
The following Smalltalk code shows a test that hardcodes the expected outcomes for the different computations. It allows for automatically checking the outcomes instead of having to print the outcomes and check by hand if they are right, and it acts as a regression test. Secondly it documents the expected outcome of the different computations.
testMoneyGivenForKids | singlePerson80occupationWithOneKidOf5 couplePerson40occupationWithOneKidOf5 couplePerson100occupationWith2KsidOf5 couplePersonWithOneKidOf14 | "cases are extracted from a database after the system has performed the computation" singlePerson80WithOneKidOf5 := extract.... couplePerson40occupationWithOneKidOf5 := extract.... couplePerson100occupationWithOneKidOf5 := extract.... couplePersonWithOneKidOf14 := extract.... "tests" "We test that the right amount of money is computed correctly" self assert: singlePerson80occupationWithOneKidOf5 moneyForKid = 150. self assert: couplePerson40occupationWithOneKidOf5 moneyForKid = 150*4. self assert: couplePerson100occupationWith2KidsOf5 moneyForKid = 150*2. self assert: couplePersonWithOneKidOf14 moneyForKid = 180.
Tests are a good way to document what the system does. By documenting business rules as tests, you guarantee that the description of the business rules will be in sync with the implementation.
The beginning of a reengineering project is a good point in time to set up a process to document knowledge about the system as explicit tests.