The document discusses test driven development (TDD). It defines TDD and describes the TDD cycle of writing a test, code, and refactoring. It outlines different approaches to TDD like outside-in and inside-out. It discusses the benefits of TDD like aiding design, promoting refactoring, and instilling confidence. It also covers test smells, misconceptions about TDD, and tools used for TDD.

1. July 19, 2016
Dhaval P Shah
Anatomy of
Test Driven Development

2. June 23, 2016
Ground Rules !

3. June 23, 2016
Scope of Session
• What is Testing
• What is TDD
• Avatars of TDD
• Why TDD
• Hands on Exercise
• Test smells
• TDD Misconceptions
• TDD Left Overs !

4. 4
Key Question?
Are we building the right product?
Are we building the product right?
Business Facing
Technology/Implementation Facing

5. 5
Brian Marick’s Test Categorization
Business Facing
Technology/Implementation Facing
SupportsDevelopment
CritiqueProduct
Before / While Coding Post Coding
• Performance / Load Testing
• Security Testing
• *ilities Testing
• UI Testing
• Usability Testing
• UAT
• Acceptance Testing
• Prototypes
• Unit Testing
• Component Testing
• Integration Testing
Automated
& Manual
Automated Tools
Manual
UI
Services
Unit
Q1 Q4
Q3Q2

6. What ?

7. 7
• Test Driven Development
• Test Oriented Development
• Test Driven Design
• Test Driven Development and Design
Perceptions of TDD

8. “People too often concentrate on the words Test and Development and
don't consider what the word Driven really implies. For tests to drive development
they must do more than just test that code performs its required functionality:
they must clearly express that required functionality to the reader. That is,
they must be clear specifications of the required functionality. Tests that are
not written with their role as specifications in mind can be very confusing to
read. The difficulty in understanding what they are testing can greatly
reduce the velocity at which a codebase can be changed.”
By Nat Pryce and Steve Freeman at ‘XP Day 2006’ conference
8
WHAT IS TDD?

9. June 23, 20169
TDD Cycle - Test, Code & Refactor
4 rules of simple design
- All tests passes
- No code smells
- Code communicates
- Minimalism

10. 10
Avatars of TDD
Business Facing
Outside
In
Out
Inside

11. 11
Outside – In TDD
Write a
failing
Acceptance
Test
Write a
failing
Unit Test
Make the
test pass
Refactor

12. 12
Basket
?
Outside – In TDD (Contd.)
?
TEST
[Calculate total
price]
Mockery
Expectations
Loyalty Point
Calculator
Promotion
Target Object
/ CUT

13. 13
Inside – Out TDD
Basket
Loyalty
Point
Calculator
Promotions
TEST
[Calculate total
price]
Target Object
/ CUT

14. 14
Differences
Classicist Mockist
TDD From Inside Out i.e. Starts with
domain
TDD From Outside In i.e. Starts with
business/feature
Works with real object Works with fake objects
Verifies state Verifies behavior
Collaborators of CUT are hard coded Collaborators of CUT are mocked
Does not lead programmers to think
about implementation whilst writing test
Leads programmer to think about
implementation whilst writing test
Test are coarse grained –
• Large Test Fixtures
• Larger Test Setups
• Less Frequent Commits
Test are fine grained –
• Smaller Test Fixtures
• Smaller Test Setups
• More Frequent Commits
Encourages ‘Ask – Don’t Tell’ based
design
Encourages ‘Tell – Don’t Ask’ (Law of
Demeter) based design

15. Why practicing TDD is
so important?

16. 16
Aids in deriving
Loosely Coupled &
Highly Cohesive Design

17. 17
Caveat !

18. 18
Helps creating live up to date
specifications

19. 19
Promotes Refactoring

20. 20
Manual (Monkey) checking by
Developers and Testers

21. 21
Stay away from (time hungry)
debuggers

22. 22
Helps developer to maintain
focus

23. 23
Instills Confidence

24. 24
Ease of code understanding

25. 25
Acts as a Safety Net

26. Hands on Exercise

27. F
I
R
S
T27
Characteristics of Test
ast
ndependant
epeatable
elf Validating
imely

28. Types of Test Doubles
• Dummy
• Stub
• Spy
• Mock
• Fake
28
Test Doubles
Dummy Test
public class DummyAuthorizer implements Authorizer {
public Boolean authorize(String username, String
password) {
return null;
}
}
@Test
public void newlyCreatedSystem_hasNoLoggedInUsers() {
System system = new System(new
DummyAuthorizer());
assertThat(system.loginCount(), is(0));
}
Fake
public class AcceptingAuthorizerFake implements Authorizer {
public Boolean authorize(String username, String
password) {
return username.equals("Bob");
}
}
Stub
public class AcceptingAuthorizerStub implements Authorizer {
public Boolean authorize(String username, String
password) {
return true;
}
}
Spy
public class AcceptingAuthorizerSpy implements Authorizer {
public boolean authorizeWasCalled = false;
public Boolean authorize(String username, String
password) {
authorizeWasCalled = true;
return true;
}
}
Mock
public class AcceptingAuthorizerVerificationMock implements
Authorizer {
public boolean authorizeWasCalled = false;
public Boolean authorize(String username, String
password) {
authorizeWasCalled = true;
return true;
}
public boolean verify() {
return authorizedWasCalled;
}
}

29. Test Smells

30. June 23, 2016
Categories of Test Smell
Test
Smells
Behavior
Smell
Frequent
Debugging
Manual
Intervention
Erratic
Tests
Fragile
Test
Slow Test Assertion
Roullette
Code
Smell
Obscure
Test
Conditional
Test Logic
Hard to
Test Code
Duplication

31. Obscure Test
- General Fixtures
- Mystery Guest
- Indirect Testing
- Irrelevant Info.
- Eager Test
- Hard Coded Test
Test Code Smells
Conditional Test Logic
- Flexible Test
- Conditional Verification
Logic
- Multiple Test Condition
- Complex Teardown
Hard to Test Code
- Untestable Code
- Highly Coupled Code
- Asynchronous Code
Test Code
Duplication
- Re-inventing wheel
- Cut and Paste Code
Reuse

32. Assertion Roullette
- Missing Assertion
Method
Test Behavior Smells
Fragile Test
- Behavior Sensitivity
- Context Sensitivity
- Data Sensitivity
- Interface Sensitivity
Erratic Test
- Interacting Test
- Resource Leakage
- Lonely Test
- Interacting Test Suites
- Test run war
- Non deterministic test
- Resource Optimism
Slow Test
- Slow component
usage
- Too many test
- General fixture
- Asynchronous Test
Manual Intervention
- Manual event
injection
- Manual result
verification
- Manual fixture setup
Frequent
Debugging

33. TDD Misconceptions !

34. June 23, 201634
Test Driven Development
=
Elegant Architecture
&
Elegant Design

35. June 23, 201635
TDD = 2 X Development Effort
Without TDD With TDD
Implement – 7 Days Implement – 14 Days
Testing – 3 Days Testing – 3 Days
Fix Bugs – 3 Days
Testing – 3 Days
Fix Bugs – 2 Days
Testing – 1 Day
Release – 19 Days
Fix Bugs – 2 Days
Testing – 1 Day
Fix Bugs – 1 Days
Testing – 1 Day
Release – 22 Days

36. June 23, 201636
Without TDD With TDD
Implement – 7 Days Implement – 14 Days
Testing – 3 Days Testing – 3 Days
Fix Bugs – 3 Days
Testing – 3 Days
Fix Bugs – 2 Days
Testing – 1 Day
Release – 26 Days
Fix Bugs – 2 Days
Testing – 1 Day
Fix Bugs – 3 Days
Testing – 1 Day
Release – 24 Days
Integration – 7 Days Integration – 2 Days
CORRECT PICTURE !

37. Return on Investment
∞
1 / Time required to
follow TDD
June 23, 201637

38. TDD Leftovers !

39. • Unit Test Framework
– Junit 4
– Hamcrest Matchers
• Mocking framework
– Mockito / Jmock / PowerMock
• Acceptance Testing framework / tools
– SOAP UI
– Selenium Driver
– Jbehave
• Automated Build Tool
– Maven / Gradle
39
Tools of the trade ! – An example stack

40. • Should be on every software craftsman’s desk
– Clean Code (Uncle Bob)
– Refactoring (Fowler)
– Refactoring to Patterns (Joshua)
– Growing Object Oriented Software guided by Test (Pryce and Freeman)
• Nice to have
– Practical Unit testing with Junit and Mockito
40
Some resources related to TDD

41. 41
Thank You !
shah_d_p@yahoo.com
@dhaval201279
https://in.linkedin.com/in/dhavalshah201279