Prefactoring

4.5. Testing Functionality

At each point in the system's development, you should create a rough draft of the tests.^[*] The test outlines can cover the basic use cases, as well as any misuse cases that might come up in the discussion. A misuse case documents how a user might unintentionally (or intentionally, with malice aforethought) interact with the system.

^[*] Eric M. Burke, a reviewer, noted, "Ideally you'd start writing tests, not just rough drafts. Also, start writing tools to automate the acceptance testing. If you develop the testing harness in parallel with the code, you will be more likely to write testable code. Failure to do this means you'll be able to write unit tests, but acceptance testing will be hard to automate."

Sam and I developed a first cut at the use cases. So now is a good time to examine some acceptance tests. Brainstorming the tests can bring up new issues that the client has not made part of his requirements. On the other hand, if you cannot imagine a test scenario that can determine that a requirement has been fulfilled, it is time to examine that requirement.

Sam, Tim, and I agreed on a preliminary list of acceptance tests that the system should pass before it is installed for production.

Use case: Checkout_a_CDDisc

• Scenario: RegularRental

  1. Enter a Customer ID and CDDisc ID.

  2. System should print rental contract.

  3. Check to see that CDDisc is recorded as currently rented.

• Scenario: AlreadyRented (Misuse)

  1. Enter CDDisc ID of CDDisc that is recorded as currently ...