Anatomy of Test Driven Development
-
Upload
dhaval-shah -
Category
Technology
-
view
54 -
download
0
Transcript of Anatomy of Test Driven Development
July 19, 2016Dhaval P Shah
Anatomy of Test Driven Development
June 23, 2016
Ground Rules !
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
Key Question?
Are we building the right product?
Are we building the product right?
Business Facing
Technology/Implementation Facing
5
Brian Marick’s Test Categorization
Business Facing
Technology/Implementation Facing
Supp
orts
Dev
elop
men
t
Criti
que
Prod
uct
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
UIServices
Unit
Q1 Q4Q3Q2
What ?
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
WHAT IS TDD?
9 June 23, 2016
TDD Cycle - Test, Code & Refactor
4 rules of simple design
- All tests passes- No code smells- Code communicates- Minimalism
10
Avatars of TDD
Business FacingOutside
In
Out
Inside
11
Outside – In TDD
Write a failing
Acceptance Test
Write a failing
Unit Test
Make the test pass
Refactor
12
Basket
?
Outside – In TDD (Contd.)
?TEST[Calculate total price]
Mockery
Expectations
Loyalty PointCalculator
Promotion
Target Object / CUT
13
Inside – Out TDD
Basket
Loyalty
Point
CalculatorPromotions
TEST[Calculate total price]
Target Object / CUT
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
Why practicing TDD is so important?
16
Aids in derivingLoosely Coupled &
Highly Cohesive Design
17
Caveat !
18
Helps creating live up to date specifications
19
Promotes Refactoring
20
Manual (Monkey) checking by Developers and Testers
21
Stay away from (time hungry) debuggers
22
Helps developer to maintain focus
23
Instills Confidence
24
Ease of code understanding
25
Acts as a Safety Net
Hands on Exercise
27
FIRST
Characteristics of Test
astndependantepeatableelf Validatingimely
28
Types of Test Doubles
• Dummy
• Stub
• Spy
• Mock
• Fake
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; }
}
Test Smells
June 23, 2016
Categories of Test SmellTest
Smells
Behavior Smell
Frequent Debugging
Manual Intervention
Erratic Tests
Fragile Test
Slow Test Assertion Roullette
Code Smell
Obscure Test Conditional
Test LogicHard to
Test Code Duplication
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
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
TDD Misconceptions !
34 June 23, 2016
Test Driven Development
=Elegant Architecture
& Elegant Design
35 June 23, 2016
TDD = 2 X Development EffortWithout
TDD With TDDImplement – 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, 2016
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, 2016
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
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
Some resources related to TDD
41
Thank You !
@dhaval201279
https://in.linkedin.com/in/dhavalshah201279