If you still haven’t read chapter 4, I recommend going back :)
Maintaining the Test-Driven Cycle
Before you start writing code for a new feature, start by writing an acceptance test. It should:
- check the system doesn’t already have that feature that we’re about to develop
- Help us understand what we’re about to write, what the system should do
- Help us understand we’re done writing what we planned to write
Separate tests that measure progress from those that catch regressions.
- Unit and integration tests should run quickly, and should always pass.
- Acceptance tests for completed features catch regressions and should always pass, although they might take longer to run.
- New acceptance tests represent work in progress and will not pass until a feature is ready.
- Start from testing the simplest success case, then while you code you’ll think of failure points and refactoring you wish to do later, so write it down on a side note and come back to it once you’re done coding the success case and see if it’s still relevant, then handle it accordingly.
2. Write the test you’d want to read: it should explain what the system should do, and when it fails it should give a clear failure message. Ignore the fact that the code that should make the test green does not exist yet.
3. Watch the test fail! make sure the failure reason is very clear so that you will be able to understand it in the future too. do not write any code before you see the test failed.
4. Develop from the inputs to the outputs:
Well, I gotta admit, this one is new to me, and makes a lot of sense. Too many times I wrote the whole class I needed, with its tests, and then found out I can’t connect it to the rest of the code and I have to make a lot of changes to make it fit. It’s very tempting to start writing the code and the unit tests that test the output of the new feature. It seems faster at first. But, you are more likely to have troubles in the integration part. You should first start by understanding the environment in which your new feature needs to fit, mock the inputs and only then move to writing the tests of the output. It will save you time in the long run.
Test the behavior and not the methods!
Had you asked me before, I would have told you that “I am almost doing TDD, cause I have a test for each public method of any newly created or existing class”. I was apparently pretty wrong. Test that you write AFTER you write the methods, are usually harder to read when you look back at it after a few months. But, If you test the feature, and not the methods, the tests would make sense after a while too. The feature-tests may have several methods called and some collaboration with neighbors. They “get something done”, and we want that something tested, and not just every path of the code (Unlike what I was taught on University on Software Testing course). We need tests that help understand how all the methods work together to create the required behavior.
I was pretty shocked when I started at Wix and saw that not every method has a test. But reading this book made me see that it makes sense: You test the feature, not the methods!
Tip: It helps to name the test with the description of the required behavior at a certain scenario.
If it’s hard to write the test it means the design of the system could be better. If writing a failing test is hard now, it will only get harder to change the system when needed in the future. Start by refactoring your code and then go back to writing the failing test. If you don’t change it now, this is exactly the point in time in which your code starts to smell and rot. Eventually you’ll find yourself writing it from scratch because you will not be able to maintain it and make it fit your customers’ new needs.
Bottom line: you should feel confident in changing your code. If you don’t, you probably need to write more tests.
Try to keep the subtle balance between the integration tests and the unit tests.
We’re on page 71 of the digital version of the book! Can you believe it?! I swear!
