Well in a previous article I insisted on why architecture was key in the IT but I totally passed aside the point on how to make your code to well structured and the main tool to achieve this is no other that automated testing.
The devil is in the details
An old danish proverb says “God is in the details” which states that all the beauty from something comes from its details.
However, while programming I would rather say the opposite as often what bring a project down are details.
Details are often what is misunderstood between us and the client. Details are often the first to be forgotten during the development. Details are what are delaying the project.
This is why we want that details to written somewhere and to make sure to always automatically check for it.
This is where automated testing enters into account.
While unit tests often don’t provide you that kind of information integration testing does.
This is why picking the right testing strategy for the right project can be vital in the hope of having effective testing and not end up failing your tests before even writing them.
Tests are your copilot
Often two brains is better than one when we try to reduce human errors and that’s exactly why there are two pilots inside a plane.
One will be actually driving the plane and will be called pilot fighting and the second one will be checking the check list to make sure the first one is not missing anything and called pilot monitoring.
However when coding often us developers are alone and our management doesn’t want to allocate another developer to the task so we end up often with one brain so how can we replicate that system into your code?
Simply by using your own brain twice by confronting your brain from the past to your current one. That might seem a bit awkward at first but it is exactly why tests have been designed and why they should always be written before the implementation.
Don’t fall into perfection
Today over-engineering is often praised but chosen technical debt is also a good way to go.
Don’t make me lie I am not telling you to make scrappy code either.
But you need to remember that Rome wasn’t done in one day and so will your code.
That way it is important to keep an equilibrium between technical debt and good practices.
This is where tests enter into account as they are a great way to balance both.
While using test driven development architecture is done on the fly and based on the needs from the code base.
In that way it is not anymore possible to over-engineer as instead of planning for potential changes that could never happen, we are now creating our architecture for the current code which is already present.
Assert you did your task not work is done
One of the most important things about testing is the ability of asserting with certainty that the task is done.
That might seem like a small thing but this is in fact the most important point about testing.
When there is only one task to track that is easy to follow its advancement but a project always includes hundreds of not thousands of them and the complexity of tracking a task increases exponentially.
Tests are providing us a state on each task by their state in a couple of minutes where manually it would take hours or even days.
However, for having that we need to create effective tests so we need to ensure that the requirements from the task are done and not the actual implementation.
For not falling into that trap there is a simple solution, always write tests before code. As you don’t know yet what you will implement in the future then you won’t be able to actually make the mistake.
Conclusion
Tests are a powerful tool which totally changes the way you work on many basis.
However, as it is code just as any part of your software it can be poorly written and become a burden. This is why you should follow some principles just as you do with your code in order to achieve effective testing.
Laisser un commentaire