"I do not write unit tests, because ..." - excuses

I deeply believe in the TDD methodology (development through testing), as I have seen in practice the benefits of it. It brings software development to a new level of quality and maturity, although it has not yet become widespread. When it comes to choosing between functionality, time and quality, it is quality that always suffers. We usually do not want to spend more time on testing and do not want to make concessions in the amount of functionality produced. If you did not plan to use the TDD methodology from the very beginning of the project, then it is very difficult to switch to it.

We all heard many excuses why someone does not use TDD, but nowhere is there a better selection of excuses collected in one place than in the book " Pragmatic unit testing for Java using JUnit " from the series " Pragmatic Bookshelf ". I read this book a few years ago and thought that no one responsible developer after reading this book would be left without the feeling that unit testing is one of the most important aspects of a developer’s work.

The most disturbing excuse I've heard is “ my code is too difficult to test ”. There may be two explanations for this. One thing is that most of your code draws UI (user interface), and automating UI tests is too complicated. I agree that automating the testing of UI is difficult (although possible), but everything that is possible should be done to automate: think about regression tests. If you have a fully automated test suite, including the UI, you can always make new changes to the code, being completely sure that you haven't broken anything.
')
The second explanation is why your code is too difficult to test - your design is too confusing. Perhaps the logic and the UI-code are too closely related, and this dependence will complicate your life if you do not have an automatic UI-test. This is where unit testing helps create a good design. Using JUnit is very simple, so if I can only select a separate layer with logic and write tests for it, I can automatically test all the logic that the UI will ever use. What? You do not have a domain model? Then use stubs (mock objects) - there are many libraries for this.

For those who have not yet read this book, I will give a brief overview of the excuses why people do not use unit tests.

• Writing unit tests takes too much time.
  This is the number one excuse. It seems that this is a consequence of how computer science is taught. In most cases, we are taught to think that testing is something that happens at the very end, and not during the whole process.
  
  The book " Pragmatic Unit Testing " promotes the "pay along the way" model, according to which unit tests should be written from the very beginning, along with how you write code, and then you will not have this nervous period at the end when you in a hurry, you will try to shove all your unit tests.
  
  Anyway, if you do not write tests from the very beginning, how do you then check that the code works as intended? Do you run it manually? Would it not be prudent to spend some time manually testing a JUnit test? After all, you have to run this piece of code more than once during the development of the project.
  
  In fact, you expect much more different temporary losses, if you do not write unit tests. You will spend time debugging, trying to understand why something is not working. Or you will have to refactor your code sooner or later, after which you will find that nothing works after refactoring. If you have written unit tests, you have a basis for confidence.
  
• Running unit tests takes too much time.
  I admit, tests that use external dependencies or work with the user interface can really work for a long time. But it is generally assumed that you should have several levels of testing. Unit test levels should run quickly. Also, you may have a certain level of integration tests, which should also run without noticeable temporary losses - just run them less frequently, for example, every night. But do not forget about the unit tests - they must be so fast as to become a natural part of the development process.
  
• It's not my job to test the code.
  I have no idea what state the developer should be in to decide that he can simply throw the finished code through the wall. If the name of your specialty was “stupid Koder”, then maybe this excuse would be even better. But your job is to develop working software, which means you must have some reason to say that your code is working . If the test department finds it difficult to find an error in your code, it will work wonders with your reputation.
  
• I can’t test the code because I don’t know exactly how it should work
  It is difficult to react without distrust. If you don’t know exactly how the code should work, how could you start writing it? First you need to understand the requirements.
  

This book lists other excuses. but these are basic. And what excuses have you heard?