"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 takes software development to a new level of quality and maturity, although it still has not become ubiquitous. When the moment comes to choose between functionality, time and quality, it is quality that always suffers. We usually do not want to spend more time testing and do not want to make concessions in the amount of functionality released. If you did not plan to use the TDD technique from the very beginning of the project, then it is very difficult to switch to it.

We've all heard a lot of excuses for why someone doesn't use TDD, but nowhere is there a better selection of excuses gathered in one place than in JUnit's Pragmatic Unit Testing in Java SeriesPragmatic bookshelf . "I read this book a few years ago and thought that not a single responsible developer after reading this book would be left without the feeling that unit testing is one of the most important aspects of the developer’s work.

The most alarming excuse I heard Is " my code is too hard to test"There can be two explanations for this. One is that most of your code draws a UI (user interface), and automating UI tests is too complicated. I agree that automating UI testing is difficult (albeit possible), but automation should everything possible is done: think about regression tests.If you have a fully automated test suite, including UI, you can always make new changes to the code, being fully confident that you did not break anything.

The second explanation why your code is too difficult to test is that your design is too confusing. Perhaps the logic and the UI code are too closely related, and this dependency 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 will be able to automatically test all the logic that the UI will ever use. What? Don't have a domain model? Then use mock objects - there are many libraries for this.

For those who have not read this book yet, 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. This seems to be 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 as you go” model, according to which you should write unit tests from the very beginning, along with how you write the code, and then you will not have this nervous period at the end when you in a hurry, you will try to cram all your unit tests.
  
  One way or another, if you do not write tests from the very beginning, how do you verify that the code works as intended? Do you run it manually? Wouldn't it be wise then to spend a little time from manual testing to write a JUnit test? After all, you will have to run this piece of code more than once during the development of the project.
  
  In fact, you will expect much more different time 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 the 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’s generally assumed that you should have several levels of testing. The unit test level should start quickly. You may also have some level of integration tests, which should also run without noticeable time loss - just run them less often, for example, every night. But do not forget about unit tests - they should be so fast as to become a natural part of the development process.
  
• It’s not my job to test the code.
  I can’t imagine 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 "stupidly Coder", then maybe this excuse would still work. But your job is to develop working software, which means that you should have some reason to say that your code is working . If the test department finds it difficult to find an error in your code, this 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 to this without mistrust. If you don’t know exactly how the code should work, how could you even start writing it? First you need to understand the requirements.
  

Other excuses are listed in this book. but these are the main ones. What excuses did you hear?