Reading Time: 9 minutes

Over the years, I've seen many different styles while doing software development. Each one has unique characteristics, and some developers can identify themselves with more than one probably. I would like to go over all the different styles and point the effect it has over the project.

The “I'm not QA” style

QA is Evil
QA is Evil

I commit the code, and then it's somebody else job to see if that it works properly. My job is to write code, not tests. I will not be able to see what is wrong with the code, because I wrote it. I need somebody else to look at the application and try to learn how it could be used, and how it could break. Usually this style indicates a big lack on documentation too, because again, this should be somebody else job. Usually this style means quality is somebody else responsibility.

No timeThe “I don't have time” style

latest report
Learn why we are the Leaders in API management and

I have to be in production in 3 weeks, there is no time to write tests. I imagine tests would do some kind of good to the quality of the application, but since I need to be in production in 3 weeks, I can skip all that formal part of the development process to deliver something working on time. I will run some manual checks once things are done, and then straight to production. This style is usually associated to consultants working 1 or 2 months on a small projects and will not be there to maintain it the next 4 years, and they just need to produce a result in short time. Documentation does not exist in this case, as it's another thing you don't do when there is no time.

The “Management fault” style

Management Anger
Management Anger

Many big companies employees follow this style. They have a history of failures and delays in the projects, so they eagerly try to cut everything that they think doesn't produce a direct positive effect for upper management. Usually this produces a large amount of functionality going into production really fast in the beginning without any test. As time goes by, the application grows, it gets more and more complex and showing progress gets harder and harder. Each new deploy means a large  amount of new bugs, plus many regressions. Within a couple of years, the trust in the application is lost, and usually there are attempts to re-write it in the new silver bullet technology.  Unfortunately, it will end up being the same in a few years just in a different technology if the development process doesn't change.

Just a Tool

The “Testing is just a tool” style

In this case, the does write tests, but only in some limited places where it was helpful in his coding process. The tests are used as a tool to create new functionality, but not as a way to increase the trust in the code. If any new functionality added breaks an existing test, the developer assumes it's because the test is wrong, and the test is changed, excluded or removed. There are tests for the application, but there is no trust in those tests. If there is no trust in the tests, they provide little value to the application.

The “Test coverage maniac” style

Maniac

Everything is about code coverage. Getting the code coverage to 100% is the ultimate goal. Looking at the coverage and looking where the tests are not going through and add a test for that path becomes a repetitive task. I might mean adding nonsense tests just to add coverage. Testing gets complicated and usually new developers have a hard time trying to understand what the code does. In this case, we are in a much better position, than in all the others, but testing is not just about coverage, it's about trust.

Trust Network
Trust Network

The “Test to trust” style

This is the ultimate style. Tests in software development have many purposes, but the most important one is to build trust in the code. If the team have trust in the tests, they have an incredible freedom to improve and change the code. This turns into greater productivity, better quality, and faster turnaround.

Having trust in the tests is not about code coverage, is about trusting your team mates they will add tests for all the important things. That if you make a change and you break a tests, then you need to think more about your change, and not just remove the broken test. Everything that adds trust into the code and tests has to be done, above solving a new problem.

Over the years I learned that testing is a critical part of a development process. The tests should run after each change in the code. Every second invested on improving the trust on the tests, is time you are winning every time you run the tests. The only way to achieve the maximum productivity in software development is not when you don't write tests, is when you trust your tests.

Are you a developer? Do you write tests for your application? Are you increasing the trust in your tests after every commit you make? Each commit needs to add trust, otherwise  you are just adding legacy code which will eventually end in rewriting the whole application.