A pragmatic quick guide to TDD
11:30 - 12:30
Testing our code is something we all know we should do. It is on the same level as we know that it is good to floss our teeth.
Testing can be done before or after the code is written. Adding tests when the code is written is a chore. It is much more fun, and we get much better results, if we use tests to drive the development. Writing the test first forces you to think of the output, and forces you to take small steps when the solution is not clear from the beginning. Writing the test first also enables you to refactor your code without being worried that you will break something.
Let’s explore test first development a bit. We are developers and we are paid to deliver working software. We need a practical point of view. Let’s use tests as drivers to build a small application live.
Getting into the habit of flossing teeth is not my area of expertise so I’ll avoid that.
Today we are lucky, we only need to build the backend. However, we need to build the backend with proper database support. And it should be thoroughly tested because we don’t want to disappoint our users and get extra work when we thought we were done.
The tool chain I will use is very much middle of the road. We’ll use Maven for building, Spring Boot for serving, and PostgreSQL for persisting. Nothing interesting to see there. The interesting part is the usage of the test of tools as drivers and good abstractions for testability.
This is a live code session and the result will be shared at GitHub at the end of the session for you to explore, play around with, and use at work tomorrow.
Thomas Sundberg is an independent consultant and contractor based in Stockholm, Sweden. He has been working as a developer for more than 25 years. Thomas has a Masters degree in Computer Science from the Royal Institute of Technology, KTH, in Stockholm. He has taught programming at The Royal Institute of Technology, KTH, one of the leading technical universities in Sweden. Thomas has developed an obsession for technical excellence that translates to software craftsmanship, clean code, test automation and continuous deployment. Definition of done according to Thomas is working software, in production. He runs a blog where he writes about programming, software craftsmanship, TDD, BDD and whatever problem he wants to share a solution for. It can be found at Think Code AB. Thomas tweets as @thomassundberg