Introduction
Here we will present a way how big problems can be solved using tests.
The main idea is to split a big task in to smaller ones. The problem is that understanding if the solution is correct may be checked only when the whole system is implemented. Here tests shine, ensuring you that a small part of the system is working correctly. This way a developer may concentrate on the next part of the system without burdening his mind with other parts.
Let's compare small, medium and big problems and the process how they are solved.
Small or medium problem
This is like jumping over an obstacle in one or two leaps.
This is an example when a developer completes a task in one day. Developer may memorize task requirements, make a task and then go home to rest.
Complex problem
This is like climbing a mountain.
If the task exceeds one working day, then it depends on a human thinking structure.
If you forget everything when you return home from your work, then you will need to spend more time the next day to remember requirements and what was done yesterday.
This human psycho-type has an advantage to take life easy, rest well even if the work is challenging.
If you do not forget requirements, then you carry everything in your mind overnight, and you continue work quickly the next day.
The problem with this pshychotype person is that he can't do any other complex work while he does not finish the main task. If the task exceeds two or more working days, then a developer becomes more and more tired, and it may lead him to overburn issues.
In my career I saw people with a first pshychotype (taking life easy). However, they can't complete a task at all if the task exceeds two or more working days. The whole day is used to remember what you need to do in this task, so no time remains for actually doing the task.
Myself, as the second psycho-type bearer, I experienced overburning many times in my job.
In my career I also saw people with the second pshychotype, who worked over day and overnight without a break to finish the task, to avoid carrying everything in their mind and not able to rest at all.
Working overnight leads to a hard readable code that contains complex errors that no one can fix, except the developer who wrote this code.
So let's consider two pshychotypes, or rather pshychotype poles in this article:
- First pshychotype: read information and forget easily.
- Second pshychotype: remember everything until a task is done.
Having all this experience, I started to think about how to avoid this overburned issue and ways to continue a developer career.
Splitting a task in to smaller parts
This is like a baby climbing stairs.
How is this related to tests?
When you split a task to smaller parts and you implement one, you need to know if the implemented part is correct. Without using tests, you do not know if it is correct because this part can't be executed separately from other parts of the task in the whole construction of the system.
Contrary: if you are using tests, you are sure each part is working correctly, at least in an isolated environment.
Both pshychotypes, mentioned above, gain a lot by using tasks split to testable parts.
First pshychotype does not need to read a lot at the beginning of the day before implementing the testable part, because the testable part is small compared to the whole task.
Second pshychotype may forget info about the finished testable part, which tests are successful, as green tests give him a psychological release and allow him to forget these tasks.
Application structure when using TDD
The presented idea above gives an understanding of how testing separate parts is important when solving a big problem.
The TDD - Test Driven Development concept requires that you write tests first and only then write code that satisfies these tests.
The splitting task idea works well both ways: either you use TDD methodology and write tests first or you write code and then cover it by tests later.
Difference starts to emerge when you actually start writing a test. After a module or function is already created, writing test to it becomes a hard task. Usually you need to use a mock technique to isolate your implementation part from other parts of the system.
Whether you are using mock technique or you are not, depends on your code structure. If you are used to work by TDD methodology, you are creating such code that using mocks is absent or minimal.
There are many ways to organize your code so it is coverable by tests easily. We will mention some ideas here.
- Avoid deep calls
- Separate a data load and storage from a calculation part
- Keep separate concerns decoupled from each other
We will dig deeper about testable code structure in another article.
Conclusions
- Tests help to split a task into smaller parts.
- Tests removes burden from a developer.
- Tests improves your code structure.
- Two phsychotype poles are presented: one forgets fast, another forgets slowly.