Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Anatomy of Test Driven Development

What is Testing
Avatars of TDD
What is TDD
How to do TDD
TDD Misconceptions
Test Smells

  • Login to see the comments

  • Be the first to like this

Anatomy of Test Driven Development

  1. 1. July 19, 2016 Dhaval P Shah Anatomy of Test Driven Development
  2. 2. June 23, 2016 Ground Rules !
  3. 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. 4 Key Question? Are we building the right product? Are we building the product right? Business Facing Technology/Implementation Facing
  5. 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. 6. What ?
  7. 7. 7 • Test Driven Development • Test Oriented Development • Test Driven Design • Test Driven Development and Design Perceptions of TDD
  8. 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. 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. 10 Avatars of TDD Business Facing Outside In Out Inside
  11. 11. 11 Outside – In TDD Write a failing Acceptance Test Write a failing Unit Test Make the test pass Refactor
  12. 12. 12 Basket ? Outside – In TDD (Contd.) ? TEST [Calculate total price] Mockery Expectations Loyalty Point Calculator Promotion Target Object / CUT
  13. 13. 13 Inside – Out TDD Basket Loyalty Point Calculator Promotions TEST [Calculate total price] Target Object / CUT
  14. 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. 15. Why practicing TDD is so important?
  16. 16. 16 Aids in deriving Loosely Coupled & Highly Cohesive Design
  17. 17. 17 Caveat !
  18. 18. 18 Helps creating live up to date specifications
  19. 19. 19 Promotes Refactoring
  20. 20. 20 Manual (Monkey) checking by Developers and Testers
  21. 21. 21 Stay away from (time hungry) debuggers
  22. 22. 22 Helps developer to maintain focus
  23. 23. 23 Instills Confidence
  24. 24. 24 Ease of code understanding
  25. 25. 25 Acts as a Safety Net
  26. 26. Hands on Exercise
  27. 27. F I R S T27 Characteristics of Test ast ndependant epeatable elf Validating imely
  28. 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. 29. Test Smells
  30. 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. 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. 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. 33. TDD Misconceptions !
  34. 34. June 23, 201634 Test Driven Development = Elegant Architecture & Elegant Design
  35. 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. 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. 37. Return on Investment ∞ 1 / Time required to follow TDD June 23, 201637
  38. 38. TDD Leftovers !
  39. 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. 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. 41 Thank You ! shah_d_p@yahoo.com @dhaval201279 https://in.linkedin.com/in/dhavalshah201279

×