Agileee 2010: Pawel Lipinski: “Clean Tests” by Uncle Paul, or How to structure your tests so that they serve you well
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.
Introduction
“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 tests that are reliable
- writing tests that they are document code
- writing tests that they are maintainable
- writing tests that they are readable
Writing good code/tests is a hard work! That require time and practice.
What test do give?
We are spending an effort on tests (a lot of efforts, actually). Why do we do that?
- Be in safe net, awareness of what you did
- TDD leads to a Test driven Design!
- TDD increasing development speed
- TDD produce documentation
Problems
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.
Process
What’s the process of creation the tests, following TDD rules?
- Think First
- Trivial First
- Test specifies “what”, implementation says “how”
- You need different levels of tests (unit, integration, end-to-end)
Conventions
Something that helps to produce clean tests.
- Coherent naming of tests classes
- Coherent naming of tests
- Test classes names focus more on functionality
Comments
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).
Test setup (Given part of test)
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.
Behavior Driven Development
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/
BDD rules
- tests names should be sentences
- simple constant template of sentence help to focus in the tests on one thing
A-TDD
Acceptance TDD. Scenarios have to written by business people (or at least with them nearby).
Tests smells
Factors that shows something is wrong with test
- Long setup
- Long tests
- Many assertions
- To many tests methods
Maintainable tests
Some rules must be followed according to have maintainable tests.
- Reuse assertion, create “business” assertions
- Reuse object construction methods
- Reuse test setup
- Tests should not depend on environment and order of executions
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.
Introduction
“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 tests that are reliable
- writing tests that they are document code
- writing tests that they are maintainable
- writing tests that they are readable
Writing good code/tests is a hard work! That require time and practice.
What test do give?
We are spending an effort on tests (a lot of efforts, actually). Why do we do that?
- Be in safe net, awareness of what you did
- TDD leads to a Test driven Design!
- TDD increasing development speed
- TDD produce documentation
Problems
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.
Process
What’s the process of creation the tests, following TDD rules?
- Think First
- Trivial First
- Test specifies “what”, implementation says “how”
- You need different levels of tests (unit, integration, end-to-end)
Conventions
Something that helps to produce clean tests.
- Coherent naming of tests classes
- Coherent naming of tests
- Test classes names focus more on functionality
Comments
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).
Test setup (Given part of test)
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.
Behavior Driven Development
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/
BDD rules
- tests names should be sentences
- simple constant template of sentence help to focus in the tests on one thing
A-TDD
Acceptance TDD. Scenarios have to written by business people (or at least with them nearby).
Tests smells
Factors that shows something is wrong with test
- Long setup
- Long tests
- Many assertions
- To many tests methods
Maintainable tests
Some rules must be followed according to have maintainable tests.
- Reuse assertion, create “business” assertions
- Reuse object construction methods
- Reuse test setup
- Tests should not depend on environment and order of executions