TIME is MONEY

TIME is MONEY. We don’t want to waste time. Can we PROVE what’s faster? Test-Driven Development (TDD) vs Test-Last Development (TLD)

Does it really matter if we write tests BEFORE or AFTER? Some might say: “I don’t have time for TDD. I want to get straight into writing the functionalities, I’ll write the unit tests after. Ultimately, it’s all the same, right? We end up with unit tests in both cases, what’s the difference?”.

TEST DRIVEN DEVELOPMENT (TDD)

1. Write the requirement/expectation in code language as a unit test (FORMAL ENCODING – PROGRAMMING LANGUAGE)
2. Run the test to verify it fails (AUTOMATED VERIFICATION)
3. Write some code to satisfy the test
4. Run the test to verify if the code works (AUTOMATED VERIFICATION)
5. Make corrections to the code
6. Run the test to verify if the code works (AUTOMATED VERIFICATION)
7. Repeat steps 5-6 until you get a working solution (AUTOMATED VERIFICATION for every repetition)
8. Refactor the code
9. Run the test to verify if the code works (AUTOMATED VERIFICATION)

TEST LAST DEVELOPMENT (TLD)

1. Write the requirement/expectation in the human language (writing it in your notebook or keeping it in your mind) (INFORMAL ENCODING – HUMAN LANGUAGE)
2. Write some code to satisfy the expectation
3. Run the debugger to verify if the code works (MANUAL DEBUGGING)
4. Make corrections to the code
5. Run the debugger to verify if the code works (MANUAL DEBUGGING)
6. Repeat the steps 4-5 until you get a working solution (MANUAL DEBUGGING for every repetition)
7. Now that you finished coding, let’s write the unit test.
8. Unit tests are painful! You realize you have to change the code just to fit the test, because the design wasn’t testable.
9. Change the code in a way to enable the unit test to be written
10. Run the debugger to verify if the code still works (MANUAL DEBUGGING)
11. Finalize writing the unit test
12. Run the test to verify if the code works (AUTOMATED VERIFICATION)
13. Refactor the code
14. Run the test to verify if the code works (AUTOMATED VERIFICATION)

TIME COMPARISON

– Both TDD and TLD must start with an expectation, which means the developer has some expectation of what the system should do. The difference is the language used. In the case of TDD, we use code language to represent the expectation; whereas, in TLD, we use human language to represent the expectation. Not much time difference.

– We can see the significant time-saving in the repetition of AUTOMATED VERIFICATION (for TDD) compared to MANUAL DEBUGGING (for TLD). The time difference is even bigger for more challenging implementations.

– TLD takes longer because we have to do double work. We have to encode the test twice, firstly in (informal) human language and then in (formal) code language. We firstly write code to satisfy our informally encoded expectations. Then we have to change the code to fit the test.

SUMMARY

– TDD is FASTER (effective).
– TLD is SLOWER (wasteful).