Test infected

Everything, everyone will write tests

3 years have passed since I saw my first red strip. What jerked me to start writing tests is no longer important. I started collecting information, re-read the entire wiki.agiledev.ru and solemnly launched my first test at SimpleTest . Of course, these tests were terrible, and the architecture too (in my current understanding). Then I probably caught most of the mistakes , but I had a wonderful time :)

Then I switched to PHPUnit - it was just interesting how it differs from SimpleTest and what is so tricky about it.

And lime - disgusting. What are the guys from symfony got into it like that? I understand the branch 1. *, legacy and all that. But 2.0 could be started with PHPUnit.

Yes, it was interesting to me. I actively wrote tests, even honestly tried to do it before writing code. Something did not work, I read various articles on the topic, as it should, and do not write tests, re-read wiki.agiledev.ru. But inside something was clearly missing.

Then Martin's Rapid Software Development book came into my hands (as always, by chance, and maybe naturally, for someone who has the Path ).
This uncle infected me with Ajile, showed what a real OOP is and gave a good kick in the direction of TDD. I still somewhere in the archives is the version of the program for calculating the number of points for the game of bowling, written using TDD (who cares, the link at the end of the article).

Since then, I have become different :) A core and self-sufficiency appeared in me, now I didn’t have to read other people's articles to see shortcomings in my code and tests. Like Miyamoto Musashi, I could learn the truth without the help of teachers.

Now my code is shit too, but now I am aware of this.

And only I was about to ascend to heaven, like Kent Beck , showed me such a focus, which I am delighted about so far. Have you ever written a framework for testing through testing using the same framework? That is, you write the code with which you write it. I tried - it is an unforgettable pleasure. Kent Beck recommends that you start learning a new language like this - write your xUnit in a new language. Ruby is waiting for me.
')
In the same place, at Beck, I met the term "test infected". So, I'm contagious :)

Why do I write tests

Because I'm paranoid and afraid of everything. When I wrote the test, I am sure that:
1. The program works exactly as I expect (each programmer always checks this, only in different ways, and not always in the most efficient way).
2. You can make changes to any part of the system, and at the same time nothing will break. Or I will immediately find out about it and easily fix it.

Therefore:

• I am not afraid to make changes to any part of the system and conduct any refactoring.
• I constantly conduct refactoring of a code, it is the integral and obligatory part of my work.
• The code doesn’t get shit and doesn’t resist change.
• I always easily, quickly and painlessly make any changes and do not feel at the same time neither fear, nor disgust for the result, nor the process.
• The number of errors in this case is sharply reduced, and those errors that are there are easily diagnosed and corrected.
• I do not spend a lot of time debugging, testing and fixing errors.
• I write code that is easy to test, and this greatly influences the architecture of the solution obtained. If the code resists testing, I understand that I have architecture problems.
• Integration problems? What is it? I pulled the thread to the master , all the tests passed. Everything.
• And most importantly - it is PLEASANT for me to work with such code. And if there are flaws (and they are always there), I am sure that when the code is covered with tests, I will fix it at any convenient time.

Way

• The value of the system lies in the tests, since only tests describe its behavior. At the same time, the code can be absolutely any (but suitable for testing). The code without tests costs nothing, it is disgusting and ugly by default .
  
  
• Test -> Prototype -> Refactoring
  Test -> Prototype -> Refactoring
  Test -> Prototype -> Refactoring
  Do not pay attention if you look askance when you mumble it.
  
  
• Tests should be written at the beginning. A test written after the code is worth nothing and is only a burden.
  
  
• First, the test should fall. This is a test test. If the test does not fall, I can not be sure that it will fall when necessary.
  
  
• Tests are written to run. A test that does not start ... and you need it at all, wasting your time and someone's money?
  
  
• I run tests every 5 minutes: one by one, in a group, the whole set. Before starting work, I run the full set. Before each commit, I launch the full set. When I do not run tests for a long time, 6 minutes, I feel uneasy. Even if I have not written anything during this time, I run the full set, and then again. Maybe I'm crazy, but now I'm a calm psycho, confident that everything is in order.
  
  
• Tests should be very fast. How then will I run them every 5 minutes? How then can I explain to the developer, inquiringly rubbing the bruised place, that before a commit you need to run a full set of tests?
  
  
• I love bugs and adore testers - they find them (bugs). Then I have the opportunity to write a new test or correct an existing one. And after that I am sure that this bug will NEVER repeat. One more step I approached the ideal.
  
  
• And finally: refactoring, refactoring, refactoring.
  
  

How to write good tests? If you have a Path, it is a matter of time.
Here, something like that .

As a conclusion

A small list of references:

• Robert C. Martin, James V. Newkirk, Robert S. Koss, “ Fast Software Development. Principles, examples, practice "
• wiki.agiledev.ru
• Kent Beck “ Extreme Programming. Development through testing "
• Kent Beck " Extreme Programming "
• Gerard Messarosh xUNIT Test Templates
• Vincent Massol, Ted Husted " JUnit in Action "

Problems for those who want to have some fun:

• Write a bowling game counting program. Rules can be found here .
• Write (test first) your xUnit framework for testing. If you are not familiar with the principles of modular testing at all, it’s better to start reading Kent Beck. And for those who know, it does not hurt.