6. 3 RULES
1. No production code until failing test.
2. No more of a unit test than is sufficient to fail.
3. No more production code than is sufficient to pass the
currently failing test.
8. TIPS AND TRICKS
Test must fail and you have to see it.
Start with simplest test that actually creates functionality.
Do simpliest implementation satisfing test. Do small
steps!
Refactor both! Code and test (no broken windows).
Sandro Mancuso - Driving well-crafted code through tests
12. WALKING SKELETON
The most e2e as possible.
Requires big effort at start of project.
Deployable app into production environment.
Architecture
Iteration zero
15. ADVANTAGES OF TDD
Improves and leads design.
Documentation & communication.
I am defining API. How I want to it looks like.
Test first vs. test after.
It is more fun.
If you test first, you think about best possible API
usage.
Deliver app in small functional pieces.
Do only what it is needed.
Good measurement of progress. It shows progress.
16. ADVANTAGES OF TDD
Good feeling and dopamin. Beware of drug adiction!
It is an programming (or agile if you will) technique.
Needn't to be apply by all team members.
17. DISADVANTAGES OF TDD
TDD alone does not guarantee successful clean code.
But you can refactor.
It is not holy grail.
You have to know design best practices and code
smells.
18. WHY I DO TDD?
“I'am tired of writing bad code... Every system that I work on I
get sick of it... it always ends-up being a mess...”
Brandon Keepers
Pure PHP -> Nette -> JTP
22. HAPPINESS
Who is enjoing bugfixing (OT)?
Development vs. bugfixing
I would like all of us are enjoying their own work. It is my
personal dream.
23. WHY NOT TO DO TDD?
No time.
No time to not write tests.
Manager forbade it.
Why does he know it?
Washing hands
It's difficult.
I agree, but mostly when you don't know how to do it
right (my experience).
Friction
24. WHY NOT TO DO TDD?
Who check that test is written right?
That’s legitimite argument.
Failing test.
I can check functionality by clicking through it.
Yes, but really?!
Consider time to build and run app vs. time to run test
(acceptance, integration).
Writing tests is boring.
No when you write test first.
30. UNIT TESTING
single unit of work in isolation
fast and readable
no prefix test, no should, don’t afraid _
no assertEquals(), asserTrue() only for boolean
one assert to one test
custom asserts, but it could hide your bad API
Martin Skurla - When
assertThat(you).understandUnitTesting() fails
31. TEST DOUBLES
Stub
Mock verify behaviour
Fake has business behaviour, simulator
Misko Hevery’s friendly objects
TheLittleMocker
34. No setUp()
public class BankAccountParserTest {
private IBankAccountParser bankAccountParser;
@Before
public void createBankAccountParser() {
bankAccountParser = new BankAccountParser();
}
@Test
...
}