Questions Answers

Questions & Answers

Q1:	Is it usual to call from fixture code into a part of the system under test?
A1:	Yes, especially in the case of testing calculations. Of course, it is important to test that the workflow also makes use of the underlying business logic code, as discussed in Chapter 35.
Q2:	Then how do I automatically test that the new logic is actually used in workflow processing, as that's the only point where the user sees it?
A2:	There are two approaches. As we've mentioned before, whenever there are calculation tests, there needs to be some associated workflow tests that make sure that the calculations are correct during workflow. Another approach is to test business calculation rules by having the fixture itself carry out the workflow actions in order to carry out the test, as we discuss in Chapter 35.
Q3:	Doesn't the first approach mean that we have to test all the possibilities again?
A3:	No, not necessarily. A few tests should confirm that the appropriate logic is being called. We take this issue up further in Chapter 35.
Q4:	My instinct would be to change the application directly. Why do such a simple first step?
A4:	It was lower risk to test the new code in LateReturns before wiring the changes into the application. Simple steps give immediate feedback, so you know you're on the right track. This also encourages better modularity. Here, Emily could develop and test LateReturns completely, without touching the application. When that was all working, she then altered the application to use the new class and tested it by running the whole application.

Emily spent the next few minutes developing class LateReturns to pass the test. She then altered the application code to use that new code.^[2] She did some manual testing to show that the change had not broken anything obvious.

^[2] This code is altered again when early returns are handled, as discussed in Chapter 35.

Don then appeared with a lot of tests, looking pleased with himself. He told us later that they'd run all the tests: "Whenever we saw red, we had fun arguing over whether the code or a test was wrong."

Note

The expected values for the calculation tests here are dependent entirely on the given values in the table. This meant that we could isolate the code in the system under test related to that business rule.

In general, the aim is to create a static method that takes all the explicit and implied given values and returns a single result, without side effects, based only on those arguments. Prior to test infecting, such business logic code is likely to be tangled with workflow-style code, so it needs to be refactored out to be independent and able to be tested directly.

The advantange of isolating the logic for a calculation-based business rule is that it is clearer and is likely to make it easier to handle a change to the business rule in the future.