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 !

shah_d_p@yahoo.com

@dhaval201279

https://in.linkedin.com/in/dhavalshah201279