Disclaimer: text below is compilation of notes I made on Agileee 2010 conference, listening to different speakers. I do it to keep knowledge I got on conference, share it with my colleagues and anyone else who interested. It is only about how I heard, interpret, write down the original speech. It also includes my subjective opinion on some topics. So it could not 100% reflects author opinion and original ideas.
One of few technical speeches on this conference. Pawel discusses a vision of production clean code, with a clean tests as key factor of creation good software. That was very interesting and rather quick, so I did only few notes of it.
“Most important stuff is to create a clean code - Robert C. Martin (Uncle Bob)”
Writing a clean code is important! Everybody knows that, but not everybody actually produce clean code. Writing a tests is vital to create reliable, maintable, code. It is a common issue of many developers to forget that tests code quality as such important as production code.
Then we do write tests, we have to be sure that we are:
Writing good code/tests is a hard work! That require time and practice.
We are spending an effort on tests (a lot of efforts, actually). Why do we do that?
The more tests you have, more problem you have with them. So, at some point of time it stop to be a documentation.
This is especially matters then you have a lot of integration tests, that could affect each other, provide massive failures without giving clear understanding what is wrong.
What’s the process of creation the tests, following TDD rules?
Something that helps to produce clean tests.
If you feel you must comment, something wrong with you code. Tests have to be document itself.
Some useful //give, //when, //then (//arrange, //act, //assert).
DRY (Dont repeat yourself) is major. We usually repeat the setup code for each tests. Have to be extracted to methods, that could be easily reused. Method name should reflect its meaning.
It is on top of TDD, we define behaviour. It reflects a user stories that business people create. Focuses, why code should exists. Code have to be a value for customer. Naming is important, language you use reflects the way you think. Naming in code is the same as names by the business people. In BDD we say Examples, Not Tests.
By the way, someone suggested good BDD tool for .NET, http://specflow.org/
Acceptance TDD. Scenarios have to written by business people (or at least with them nearby).
Factors that shows something is wrong with test
Some rules must be followed according to have maintainable tests.