This is an archived version of the course. Please find the latest version of the course on the main webpage.

Chapter 9: Testing and debugging

Test driven development

face Josiah Wang

Back in Lesson 5, you have been introduced to the concept of automated testing. If you remember, the idea behind a ‘test-first’ approach to software development is that you write your test code first to understand the expected the behaviour and requirements of a function you wish to implement. And then you implement your function.

Towards the end of Lesson 5, you have also written a test function test_manhattan_distance() when developing your manhattan_distance() function.

I have introduced assert statements which should make it easier for you to write automated tests.

Now, I only asked you to implement one test function. But is that enough? If you only have one test that passes, it only demonstrates that it only works correctly for THAT case. Will you be confident that your function will also work correctly for other cases? Could there be cases where your function will fail? Especially ‘difficult’ cases?

To be more confident that your code is correct and works for all cases, you can (and should) write more tests for the function. If you write your tests extensively enough, you can greatly reduce the chance of your functions resulting in an error, and having to debug it after development.

This is the whole idea behind what is known as test-driven development (TDD). The term ‘test-first’ I previously used is actually just an older term before TDD came along. TDD is the preferred term nowadays. Developers like to think of tests as driving your whole development process (“test-first” is only one of the aspects of TDD).