TDD is popular, but honestly how many developers like to write tests? Test-driven development is considered a luxury and can be only afforded by developers with a lot of time on their hands. It has the same fate as software documentation.
New developers tend to do that with print statements. and not write test code and for that most of their development never sees the need for doing it they are not wrong why? because they don't build a large or critical software
works well when building small programs that is where coverage comes into the picture we will teach you that but that is later only once you are ready with the basic we can start with a complex project
I learned writing unit tests from youtube since writing code unit testing isn't taught in colleges. Even though its a basic skill ill give you the importance of it imagine you are making a car and you are building a tire are you going to fit the tire in the car every time you fix the tire and run the car and see if the tire is working perfectly? yes?
Bridgestone - Indoor tire testing (2009)
you must set up a testing unit precisely to test the tire
yes a running car with the tire will not cover all cases in a test system, you can cover many cases like run it under extreme temperature conditions extreme breaking but not with an actual car, unless that test is meant for the car as well this is the building block of any form of engineering
all units must be tested separately before assembly with their unit test machines specifically designed for that purpose
Not using Unit Testing
So here goes the list of sufferings as we can say of not using unit tests
Steeper learning curve for new developers about the module in question
For a new developer joining the team, it helps them understand the code with unit tests. They act like several main programs for a software unit. Since most software units will not have a main program.
Less clarity for functional requirements in code
Unit tests reflect the functional requirements. They tell us how the unit of the software will be used. The more business cases are covered in tests the better the code coverage. This helps improve clarity over the exact functional requirements. The test cases can be used to discuss functional requirements.
Looking for bug in the wrong unit
OK now this is the most lethal drawback of not having tests. Most development teams suffer with this. And this accounts for the time spent in writing unit tests. When development teams are writing tests, they are investing in future. It is easier to localize the problem and solve them. It is easier to trace the error.
Even the best engineers can't fix the issue if they are debugging the wrong piece of code
Mocking
Unit tests cannot use components which it will be later assembled with. In such a case we use mocking. Mocking is a way of provide other unit behavior to this unit. You can find multiple articles on the Internet about Mocking the popular library to perform mocking. Mockito is used in the java ecosystem.
Code Coverage with Testing
Code coverage helps us understand, what percentage of the code written is being actually used across all test. Unless we write tests, they will be no measure of coverage. Coverage is a measure of efficiency of the code written.
Less is more. Best code is no code
Popular code analysis tools like Sonarqube prefer code coverage of 80% or more. That is a high ask. You will see huge improvement in quality if the coverage over 50%. You most important cases will be covered due to Pareto principal.
Here is a tutorial to setup code coverage for a maven project.
