Design for Approval Testing

Extra challenge with dates, process ids, things in random order.

Connect - is testability an architectural concern?

Is it acceptable to re-design your production code to make it more testable? What kinds of things might you want to change in your architecture? Have you changed anything in your architecture purely for the sake of testing?

Hopefully they will mention controlling the current time.

Concrete - analyse why the tests are failing and how to fix them

Use the java, C++ or python version of Supermarket Receipt starting on the ‘with_date’ branch. All the tests are currently failing.

Don’t implement the strategy straight away. Discuss in a group the best solution.

Demo - pre-comparison processing

Demo a solution that fixes the problem by setting the date in receipt to be a fixed, known date.

Concrete - fix the problem in your own way

Look again at the strategies you came up with. Pick one and implement it. Alternatively implement the same one that was demoed.

Concept - pre-comparison processing

There are several points you can fix the output to make it suitable to use for approval.

For documentation for using Scrubbers:

Conclusions

Which strategy do you prefer? Is it acceptable to change the production code to improve testability?