Although the first condition when developing software is that the program must meet the user's requirements and works correctly, this is not the only and final requirement for the software. Unfortunately, we sometimes overlook this when writing software.
PS: The article is based on the personal opinion of the author. It is not intended to demean or exalt anyone. Long story short,
let's have fun...
What is a well-written program?
A program that is easy to follow, easy to expand/extend, and easy to respond to change, easy to maintain is considered a good program.
"Deadline is almost here, I'm not even halfway through the task yet."
It's a familiar sentence, isn't it?!
In this article, I will talk about why we write Unit tests in a few projects or not at all, and what advantages we gain if we do.
Of course, you can say that the quality of the program does not depend only on unit testing.
I have seen very well-written code without unit testing. Believe me, I'm telling you from my own experience))
PS: The purpose of the article is to encourage people to write unit tests from time to time.
Why don't we write unit tests more often?
1) "Deadline is almost there".
When setting tasks, deadlines are unrealistically short in many companies. I have seen with my own eyes 30-day work as a request for 2 weeks. WTF? In many cases, the main reason for this is that the person in charge of the work does not evaluate the task correctly, and the person accepting the task is silent about this "oppression".
It is necessary to sit down and analyze the issue properly with the relevant people, justify your opinion during the meet-ups, and set the right deadline.
2) "F*ck it and deploy it"
In some companies, no methodology is applied at all. Unfortunately, most of our companies are like that.
Lack of methodology greatly reduces the software development process and quality.
Here we are not only talking about de facto methodologies.
Incorrect assessment of the time allocated to writing tasks, lack of control over the quality of the programmer's work, and the fact that the programmer "says, let the main fire work, then refactor, and release poor code to production".
Not only lack of module tests, but also integration tests and End-to-end tests.
3) The programmer cannot write unit tests.
Most companies only check technology knowledge when hiring an employee. But in my opinion, there is some default knowledge that every programmer must know. For example, writing unit tests.
4) The programmer writes a bad unit test, and in the end, instead of production code, he is busy compiling the branch head of the unit test. Unit testing is like production code, if you feed it with bad code it will turn around and look at you. This is a fact!
5) The company does the work in the minimum time so that it incurs minimum costs. Projects that should normally take 8-9 months usually take 3-4-5 months. Because, for example, if there are 3-5 people in a small team and they are paid monthly, for example, $$$$, they save the budget by cutting the project time by 3-4 months.
6) To Analysis and design are given little importance, or it is generally assumed that the process of writing software consists only of coding.
At this time, little or no time is allocated to stages such as testing, analyzing, writing unit tests, and projecting the program. For some reason, some of our developers think that writing a program starts without coding. However, they forget processes such as analysis and design.
So what does unit testing do for us?
- Unit testing serves software architecture. So there is such a conversation: Test Driven Development. Before writing the program parts, we first write the test (Test First approach), then write the program for the successful passing of the test. TDD is not unit testing, but it helps us build a loosely coupled modular structure that responds to change through unit testing.
- Unit testing saves time. If the program consists of several pages and forms, instead of testing them one by one, reaching that stage and doing a real test, we can check whether the business process and code are working by simply running the module test written in that business rule in a short period (within seconds). This is a fast and time-saving process that goes through each page and form and saves time many times over manual testing.
- Unit testing makes us feel confident. If the unit test is written correctly and passes successfully, we can be sure that the code we wrote is working correctly.
- Unit test scenarios help the developers who take over the work after us to understand what happened in the project, it plays the role of a kind of documentation.
- Minimizes errors in the program and helps to find the error more easily if there is an error.