Do you want our logo?
Do you want our logo descriptionKnow our brand.
Do you want our logo descriptionKnow our brand.
Recently, the methodology Test-Driven Development has become a way of working and a change of mentality in the IT world, but unfortunately there are always exceptions within this sector, be that due to mentality (“this is worthless”) or because of deadlines that hurry us (“this is a waste of time”).
We will try to explain by introducing what it consists of, what are its basic principles, what it means to implement this methodology and what advantages it brings us.
TDD are the initials of Test Driven Development. It is a process of development that consists of continuously encoding tests, developing and refactoring the built code.
The main idea of this methodology is to make initial unit tests for the code we have to implement. That’s to say, first we code the test and, then develop the business logic. It is a somewhat simplified vision of what it supposes since from my point of view it also gives us a wider vision of what we are going to develop. And in a way, it helps us to better design our system (at least, it has always been that way in my experience).
So that a unit test is useful and this methodology is successful, before starting to code, we need to fulfil the following points:
Some of the principles on which TDD is based are the denominated SOLID principles. For those who haven’t heard of them, here is a brief description:
The lifecycle of TDD is based on a continuous coding and refactoring. How can we do this?
On the different projects that I have worked on throughout my professional career, I have found myself with the impossibility of introducing or encouraging the people in charge to change their work philosophy (not always, thankfully).
As I said at the start of the post, we have always found ourselves with the typical cases in which they don’t see any use in implementing said methodology. The “excuses” are always the same, from “this is worthless”, “we don’t have time”, “I’m not used to…” In general, and in my point of view, these phrases come from ignorance and the lack of vision at the time to see its advantages. I myself thought that at the start (when you’re young you say lots of silly things), but when you see it’s not like that…
In general, the projects where I have used TDD, it has helped me to detect requirements that the business was missing, to better design my business logic by separating components and layers (it helps in certain cases when a member of the team is very willing to dock in too much code), and prevent errors.
I do not know if it will have been good luck (although in our sector we know that normally luck isn’t on our side regarding complete development), but on these projects the number of errors has reduced drastically in comparison to others where I have not used TDD (there are also other factors, like the technical part, the organisation and the communication that obviously have an influence).
For the programmer, it is a huge change in mentality in their way of processing and managing information. It’s hard to get used to it at first, but there comes a moment in which their productivity and efficiency at the time of coding the test and developing the code in a simplified way increases and ends up very productive.
If a test is well written and well defined, we can almost assure that our business logic is correct and that what can fail in a possible incidence can come mainly from the data that the external systems provide us with. That is also a way of fencing in errors.
For example, not long ago I found myself a case in which the shipping costs of a purchase were €0. As I knew this was quite improbable that my development was the cause (since it was already well covered by the unit tests), I realised that the error came from an external cache that was refilling a series of tables, whose purpose was that of returning a series of necessary fields to calculate the cost.
In the end, you save time debugging and you quickly and efficiently focus on the possible problems. This translates as fewer maintenance hours and “diving” into the code so you can see what is failing. Something in which might have taken 1 hour, took only 10 minutes in deducing.
The main disadvantage that I see in this methodology is that it is not valid (at least in my opinion) for integrated test, since we need to know the data of the repository and verify that the content is that which desired after carrying out a system management transaction for a BBDDD (even in memory, which would be ideal).
For these type of integrated or functional test there are frameworks such as Concordion that offer interesting solutions, although that is a topic which we can talk about in another post.
So, what are the benefits TDD offers us?
I encourage you to try this way to develop your applications as much as possible, (in my point of view it’s worth it), or at least that you know it, because every day it is more widespread in our sector.
And of course, I do not have the absolute truth, because within each work team there is a discussion about how to carry it out in the best way possible and surely have missed many things, although a post at the end is reduced to trying to explain and develop in a simple way an idea based on the experience
Lastly, I recommend the book by Kent Beck, “Test Driven Development: By Example”, Very interesting material by one of the gurus on this topic.
Comments are moderated and will only be visible if they add to the discussion in a constructive way. If you disagree with a point, please, be polite.