Growing Object Oriented Software Guided by Tests — Chapter 4
If you haven’t read the previous chapter, go back to chapter 3!
“We should be taught not to wait for inspiration to start a thing. Action always generates inspiration. Inspiration seldom generates action.” — Frank Tibolt
You should have a system that enables you to build, deploy and test before you start writing any code!
So you’re gonna test a walking skeleton.
Step 1: Work out how to build, deploy, and test a “walking skeleton”. You need a general clue about the major system components needed to support the first planned release. You should be able to draw the design for the “walking skeleton” in a few minutes on a whiteboard. Tip: Keep a drawing of the structure of the system on the white board where it’s visible for the whole team and keep it in mind while coding! Make the smallest number of decisions you can to kick-start the TDD cycle. Then, we’ll learn and improve from real feedback.
Step 2: Use the infrastructure to write the acceptance tests for the first meaningful feature. Focus on the structure and not about cleaning up the test to be beautifully expressive.
Step 3: Start the test-driven development of the rest of the system.
We want our test to start from scratch, build a deployable system, deploy it into a production-like environment, and then run the tests through the deployed system.
Why would we want the deployment step in the testing process?
- To make the process error-prone — it should be automated and the scripts that deploy our code should be in continuous use so that when we really deploy they work smoothly. You will understand the deployment process better when you automate it.
- Deployment sometimes depends on other people outside the Dev team. If you need to add a DB or get QA’s approval you should know that process right away and not two weeks before delivery.
When we release regularly to a real production system, it allows the system’s stakeholders to respond to how well the system meets their needs, at the same time allowing us to judge its implementation, and change and evolve the system according to the feedback.
A test-first system ensures you’ll have regression tests. Regression tests enables changing code without fear of breaking production. When we deploy frequently, we can make required changes according to the customer’s changing needs.
Comparing TDD and non-TDD:
TDD has an overhead at the beginning of the project, in building the walking skeleton (test and auto-deploy infrastructure). But the initial cost of building the “walking skeleton” will pay off later. At the beginning of the project we still have time, money and patience to build it right.
Non-TDD has a fast pace development speed at the beginning of a project but a slow and very stressful development experience towards the expected deadline of the release.
What if my project already exists?
Start by automating the build and deploy steps. Then, every time you want to refactor existing code or add a new feature, you should first write an end-to- end test. This will enable detecting regressions, and you’ll feel safer making changes. Test the “happy path” first, then go into the more complicated flows.
I know this is the part you like best. We’re now on page 63 (!) of the digital version of the book.
What’s next?
Read on to chapter 5!
