This document discusses test-driven development (TDD) and behavior-driven development (BDD). It covers the core principles and rules of TDD, including writing failing tests first and then code to pass the tests. The benefits of TDD are described, such as improved design, documentation, and catching errors earlier. Challenges with TDD are acknowledged, but it is argued that with experience writing clean code and following design best practices, TDD can help developers write higher quality code. Tools for writing tests like Hamcrest and AssertJ are also mentioned.

1. TDD
TEST DRIVEN DEVELOPMENT
Created by /Jakub Koci @jakubkoci

2. DISCLAIMER

3. TESTING
London school (outside-in) vs. Chicago school (classic)
Unit, Integration, Acceptance (e2e)
New code vs. legacy

4. QUALITY
External vs. internal quality

5. TDD

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.

7. TDD LIFECYCLE
1. Write failing test.
2. Write implementation to pass test.
3. Refactor (if it's needed).

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

9. BDD
BEHAVIOUR DRIVEN DEVELOPMENT
Tests as specifications of features.

10. BDD VS. TDD
TDD doesn’t mean (only) unit testing.
BDD is TDD doing right.

11. 2-PHASE LOOP
Acceptance test + RGR with unit tests

12. WALKING SKELETON
The most e2e as possible.
Requires big effort at start of project.
Deployable app into production environment.
Architecture
Iteration zero

13. WHY?

14. WHY TO TEST?
Checks functionality, regression.
Allows changes.

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

20. CLEAN CODE
Clean code -> Still not enough

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.

25. THEORY VS. PRACTICE

26. HOW?

27. HOW TO WRITE TESTS?
Who have never done any test?
All of us are doing tests.
It's misleading question!

28. HOW TO WRITE TESTABLE CODE?
That's the problem!
Misko Hevery's blog and talks
SOLID

29. HOW TO WRITE TESTABLE CODE?
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

32. PRIVATE METHODS TESTING
Don't do that!

33. CODE

34. No setUp()
public class BankAccountParserTest {
private IBankAccountParser bankAccountParser;
@Before
public void createBankAccountParser() {
bankAccountParser = new BankAccountParser();
}
@Test
...
}

35. assertEquals(...)
@Test
public void testParseReturnConvertedBankAccount() {
String accountNumber = "86-1561261133/0100";
BankAccount bankAccount = bankAccountParser.parse(accountNumber);
assertEquals("000086", bankAccount.getPrefix());
assertEquals("1561261133", bankAccount.getAccountNumber());
assertEquals("000100", bankAccount.getBankCode());
}

36. assertThat(...) with Hamcrest
@Test
public void testParseReturnConvertedBankAccount() {
String accountNumber = "86-1561261133/0100";
BankAccount bankAccount = bankAccountParser.parse(accountNumber);
assertThat(bankAccount.getPrefix(), is(equalToIgnoringCase("000086"
assertThat(bankAccount.getAccountNumber(), is(equalToIgnoringCase(
assertThat(bankAccount.getBankCode(), is(equalToIgnoringCase("000100"
}

37. assertThat(...) with AssertJ
@Test
public void testparseReturnConvertedBankAccount() {
String accountNumber = "86-1561261133/0100";
BankAccount bankAccount = bankAccountParser.parse(accountNumber);
assertThat(bankAccount.getPrefix()).isEqualTo("000086");
assertThat(bankAccount.getAccountNumber()).isEqualTo("1561261133"
assertThat(bankAccount.getBankCode()).isEqualTo("000100");
}

38. Test method name
@Test
public void parse_accountNumberWithDashAndSlash_returnBankAccount() {
String accountNumber = "86-1561261133/0100";
BankAccount bankAccount = bankAccountParser.parse(accountNumber);
assertThat(bankAccount.getPrefix()).isEqualTo("000086");
assertThat(bankAccount.getAccountNumber()).isEqualTo("1561261133"
assertThat(bankAccount.getBankCode()).isEqualTo("000100");
}

39. One assert on test method
@Test public void
parse_accountNumberWithDashAndSlash_returnBankAccountWithAccountNumber
String accountNumber = "86-1561261133/0100";
BankAccount bankAccount = bankAccountParser.parse(accountNumber);
assertThat(bankAccount.getAccountNumber()).isEqualTo("1561261133"
}
@Test public void
parse_accountNumberWithDashAndSlash_returnBankAccountWithBankCode() {
String accountNumber = "86-1561261133/0100";
BankAccount bankAccount = bankAccountParser.parse(accountNumber);
assertThat(bankAccount.getBankCode()).isEqualTo("000100");
}
@Test public void
parse_accountNumberWithDashAndSlash_returnBankAccountWithPrefix() {
String accountNumber = "86-1561261133/0100";
BankAccount bankAccount = bankAccountParser.parse(accountNumber);
assertThat(bankAccount.getPrefix()).isEqualTo("000086");
}

40. TOOLS
Hamcrest
AssertJ

41. RESOURCES
Clean code, Robert C. Martin
Growing Object-Oriented Software, Guided by Tests,
Steve Freeman and Nat Pryce
My TDD playlist on YouTube

42. QUESTIONS?

43. THANK YOU