Why test driven development sucks but why you still should do it

Hey, you still reading after seeing test driven development in the title, well done. Let’s face it, testing is nothing that a software developer enjoys to do. It is lot of work, you need to think of many different cases and as your application is deployed the first test that the customer does is something you never thought about. We all know that feeling.

Especially when software is increasing it gets more complicated to test. What is the best aproach then? Of course, one option would getting a tester for your team. But what happens then? Omg, 10000 bug tickets, great, isn’t it? So today I would like to talk about some better ways of testing software and how you can integrate such processes in your existing development process.

Maybe lets start with some basics. There are different testing techniques. The application may be tested manual by someone clicking through all processes. This approach is the one that is used at first most of the time first because obviously it is the easiest thing that also the user does. Some of you may also now frameworks that do that part of testing automatically for you. As explained, this testing technique can be done without many knownledge of this topic. But what you need to keep in mind that when an application gets bigger there are many preparations need to be done to just test some piece of logic you just implemented. That is why there is another testing technique called unit testing. Unit testing is a technique to test the most granular piece of logic you have – in programming terms that means that you test methods. Unit testing is done via writing code logic that tests your code that you wrote. With unit testing you will only test one unit of the logic, meaning that you should not use other units of the application for that. This is because you focus on testing only the logic. Because you may need to test also the behaviour your class has in the context of a bigger part of the application there is also something between the described techniques, this one is called integration testing.

So, next, what is test driven development. It is a way of creating software by thinking first about tests your new logic requires. Literature mostly describes that technique in terms of unit testing meaning that you first create or unit tests and then writing the logic. But in my mind this can also be done at a much higher level. You can also do “test driven development” by formulate tests while creating a new requirement. As a product manager/owner/requirements engineer this is something you do while thinking about requirements anyway. Something like “ok, when I click there I would like this to happen”. By using testing cases while formulating new requirements software engineers will understand the requirements better too. And it could also lead to other test cases by the software engineers or even better ways of doing the same. In a scrum way of creating software I would suggest to add a section in the user story that is covering all the test cases. And that test cases will be used to show how everything should work. This section must be of course flexible because there may be cases where software engineers think of new test cases needed during development.

Alright, now let’s move on to code testing. I think that creating unit tests for your code is essential especially when you are working on a project with different software engineers. That is because such unit tests can be seen as an approve that the whole logic works. Think about new features you develop and during development you may adopt some pieces of code in backend. Wouldn’t it be great to have something that makes you sure that all the other pieces will still work? Unit tests make that happen if they are included in the build. And here comes the most important thing, NEVER, and I really mean NEVER create a production build with some “build-skip-tests” flag. Once done everybody will do that and therefore nobody will care about tests. And when you finally think, ok, maybe let’s fix the test you will end up getting very frustrated because lot of work will be needed to be done.

The amount of time you need to write unit tests isn’t low, that is true. But if you think of the amount of time you would need to retest everything in a complex product just to see if your piece of code didn’t broke any functionality the effort of writing tests is totally worth it. It is much faster to develop pieces of logic incrementally and test the code by the created unit tests. Also, if you write unit tests before writing the class you gonna see that you will think more about the structure and the requirements that this piece of logic should cover. And programming by trying out things is, as we all know, normally not the best way of doing things.

Writing unit tests will also lead to a kind of documentation for the code. Just think of when you last got into a project with thousand different classes covering lot of logic. You normally need lot of time to understand where you should put some code. If the project is well tested and for all logic pieces a test exist you will notice that engineers will first check out the tests and with those tests they can understand the logic. Of course, you can achieve the same by comments in the code, but what project does not include deprecated comments? Deprecated test cases are not possible, because if they cover some old logic they will fail. That is why developers will adopt tests when adding new logic. And that leads to some kind of documentation for the code.

Tests can also be used for new employees to get into the companies way of coding. Together with an experienced developer the new employee could start with creating a unit test for some logic that the senior is then implementing. After some rounds the setup can also be changed that the new employee is writing the actual piece of logic. By doing that the senior could explain frameworks/base methods and so on and the new employee is able to find out how everything works.

Test coverage is a measurement to identify how many lines of your whole application are covered with tests. When companies try to add unit tests they often include a “100% or at least 90% code coverage” strategy. 100% of code coverage would mean that all lines of your whole application are tested, also those boring getter and setter methods. And I have a problem with such strategies. It is simply not possible to cover all code pieces. In my mind all important parts that contains logic must be tested. By that I mean business logic classes, complex calculations and so on. Some code of a framework, like a spring repository in java, is nothing that will not work. Therefore I don’t think you need to test these.

E2E testing is a technique that is used for testing the whole application by something that really clicks through a deployed app. So instead of manually testing everything an automated part will do that. This kind of testing is used to test parts of the application that are not very complex to test but testing these all the time would cost lot of time. By creating E2E tests you will increase the quality of your application since it is testing the whole thing over and over again. But those kind of tests need an application setup that not everybody has. For web applications for instance without ids on all the dom elements it is very complicated to address different pieces of the application. Also such tests are very complex and timeconsuming to create. It is neccessary to create a presetup of the test, than all the tests are executed and then all the things need to be deleted again to not create negative side effects. Also running those tests need many time since they really simulate a user doing things in the application. Therefore such tests should not be included in every build but they should be executed at least once a day. I think E2E tests make sence for application parts that are very boring and repeatable to test like some sign up process. Including such kind of tests needs some preparation and also must be calculated in terms of the time effort that they need.

Alright, those are my thoughts of testing software. What is your experience and which testing technique is your favourite?