What should go on my test code? Unlike we think, it is a common question among the developers - main the newcomers - that advendure themselves in the world of programming. To start talking about this topic, some questions need to be answered and one of them is: "what are tests and why are they so important?". Tests are not only pieces of code responsible for ensuring a behavior in your main codebase, they tell you a story, they are responsible for teaching you things about your just-finished code that you did not even know.
But... Why does all these fine words mean? Basically, they tell you that tests are not exactly focused on ensuring behaviors that are already expected but the ones that we are not really expecting, and this is a really hard task that requires not only technical knowledge, but business knowledge about what you are doing. Tests are not meant to verify the basic, check database connections correctness or even validate classes and methods, their real and glorious objective is to ensure that - technically - your application mets all the requirements to be reliable to execute your business rules.
The main responsibility of a test is to track and ensure consistent behaviors that composes the pipeline to execute your business rules in a reliable way with meaningful causes and effects.
Meaningful causes and effects
Every effect will have a cause - and this does not change in the context of your application. Look at your final users as unpredictable sources of different causes that will end on different effects. Create your tests based on that concept, try to explore and select ways that your users have to possibly break your application. Also learn from past mistakes, creating tests that are responsible for trying to reproduce previous bugs and may fail.
Thinking on resilience and reliability
In the most basic meaning of the words that can fit for that context, we can identify "reliability" as the capability of your system to survive to expected causes such as power outages, denial of service attacks, cloud outages and environmental causes that usually happens time to time. But the main challenge of any development team is to ensure resilience - the capacity to handle unexpected problems - I mean - the capacity to handle problems like invasion attempts, unprompted system breaks and other random problem. This kind of capacity is not directly related to "how should I solve that problem automatically?" and more like to: "what should I do to avoid that compromised part breaking the rest of the system? how can I properly isolate my current problem and also gather sufficient information that will be sent to my logs to future troubleshoot?".
Conclusion
Testing can be tricky. Testing don't work only as a way to "see if something else is breaking", but a direct tool to act as a truth source during a project development. Tests are meant to be meaningful, to ensure resilience and make sure your project is following consistent patterns in order to attend your customers in the most profitable way.
Top comments (6)
Interestingly, I've been a professional developer for almost 30 years and have extremely rarely used any form of automated testing. Some developers at some companies chose to write tests, but I've never worked anywhere where they were required or were part of the development culture. This does not seem to be specific to any industry either - I've worked for e-commerce platforms, online payment providers, online travel agents, image/media library platforms, government service providers, property platforms, and currently in the gaming industry... and testing has not been a 'thing' in any of them.
That's concerning and unfortunately the reality of our working area. Tests should be more present in developers and companies day-to-day.
Why? I don't see it as a bad thing at all. I guess I'm probably an advocate for not using automated testing.
You need to have a consistent way of checking if the behavior of your solution is correct. Humans fail, with tests that can be constantly aprimorated that problem gets smaller at every update. It's also easier to find edge cases and this will cost you less than spending too much time to make manual testing.
Thirty years of experience has taught me differently...
Automated testing encourages a "hands off" approach to code and an over-reliance upon 'information' that is (hopefully) contained within tests written by others (that may or may not be up to date, or even correct).
Overall, a project is much better served by developers who have developed their own knowledge/understanding of the code they are working with. This end is much better achieved by manually testing the changes you make to code you are writing/maintaining/fixing. Yes, this might be slower initially - but you'll end up much better equipped to continue working on the project.
Automating the testing process - in my experience - contributes to the siloisation of project knowledge and understanding... degrading the teams overall ability to work on and have a shared understanding of, a project.
Lewis Mumford, Humanist and philosopher of technology - 1970
Do what you think it's better for your business