Deep beneath the team lies an architectural implementation which gives us peace of mind when we deploy software. It is called Test Driven Development (TDD). I’m not going to go into the protocols or rules of TDD, just a fun opinion of the freedom that it provides.
We as programmers experience problems in software all the time and sometimes we are the very person who created the bug or problem in the first place. That is human nature and as with any structure it can be either good or bad.
Reducing bugs in code is as simple as running a test framework of some sort – depending on the language you are programming in. All code that you write should be covered with tests in order to tell you if production code you have changed just broke your application. You want the green light mentality.
Safe code equals safe deployment. Ship that shit!
Freedom of Test Driven Development
The test suite gives you the freedom to break standards XD
Fully Covered Code
With your tests covering all of your production code, the team or future developers can make changes knowing that tests will break.
When you write tests for your production code, you can have fun and be creative. In some cases you may not even have to follow PSR. All you have to do is write logical tests as a base for your production code.
Solidifies Clean Code
Using a test driven architecture forces you to work on refactoring code. It has a positive impact on the way that we see and read our own code, wanting to improve it.