Is this how you hate unit testing?
Upcoming SlideShare
Loading in...5
×
 

Is this how you hate unit testing?

on

  • 1,610 views

 

Statistics

Views

Total Views
1,610
Views on SlideShare
1,609
Embed Views
1

Actions

Likes
2
Downloads
10
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Is this how you hate unit testing? Is this how you hate unit testing? Presentation Transcript

  • www.odd-e.com I hate unit testing!!!Friday, 9 December, 11
  • Who am I? • Name: Steven Mak • Agile Coach at Odd-e • Lives in Hong Kong • Agile, TDD Coaching • I love coding - Java, C/C++, PHP, Perl, and some weird ones • I speak English, Cantonese, and Mandarin 2Friday, 9 December, 11
  • 3Friday, 9 December, 11
  • I HATE UNIT TESTING! • Doesn’t catch many bugs • Still need to do integration tests • Waste time 4Friday, 9 December, 11
  • Need to test at integration level anyway? Is this what you mean by integration testing? 5Friday, 9 December, 11
  • How many tests do you need to cover through system level tests? 10 states Tests 5 interactions 5 interactions 10 5 interactions 10 states states • It would take 1000 (or more) tests to this simple system! • System Level Tests just cannot be thorough 6 Adapted from: http://www.renaissancesoftware.net/files/sglon/LondonScrumGathering-v1r0.key.pdfFriday, 9 December, 11
  • The down side • Tons of them to write • False sense of security • Integration tests are slow • Hard to diagnose • Brittle - one change would trigger many test failures 7Friday, 9 December, 11
  • Test Automation Pyramid You are going to need some integration tests, but not in the way you do like unit tests. 8Friday, 9 December, 11
  • Write good focused unit tests • Don’t test the platform. • When writing a single object to test with other collaborating objects, use interfaces for those other points. Interfaces are not the actual collaborating object. • Leverage the interfaces so you don’t need to actually test the other objects. • Test the single object to speak to itself, i.e. State Tests • Create your focused Collaboration and Contract Tests. http://b-speaking.blogspot.com/search/label/integration%20tests 9Friday, 9 December, 11
  • Collaboration and Contract Tests • Collaboration tests: - Do I ask the collaborators the right questions? - Can I handle the collaborators’ responses? • Contract tests: - Can the interface accept the question being asked of it? - Can the interface supply the responses expected? 10Friday, 9 December, 11
  • Example: We are assuming that @Test compareTo() would return 1 public void with_arguments(){ if we pass in “Test” ! MyCollaborator c = mock(MyCollaborator.class); ! when(c.compareTo("Test")).thenReturn(1); ! assertEquals(1,a.doSomethingElse("Test")); } @Test public void compareToShouldReturnOne(){ We write a test for the real ! ! MyCollaborator c = new MyCollaborator(); MyCollaborator.compareTo() ! ! assertEquals(1,c.compareTo("Test")); } Contract tests are usually slow but tend to be stable. Often running just once a day is plenty 11Friday, 9 December, 11
  • Refactoring? Code smells! Code stinks! It’s no fun writing unit test if you don’t spend time refactoring 12Friday, 9 December, 11
  • Why? How? opportunity for refactoring amount of code smells O indicates motivation developers O amount of bad code quick hacks # of bugs panic time spend on bug fixing 13Friday, 9 December, 11
  • Refactoring visualized Without refactoring: Original program: Making changes: More changes: 14Friday, 9 December, 11
  • Refactoring visualized Without refactoring: Original program: Making changes: More changes: 14Friday, 9 December, 11
  • Refactoring visualized Without refactoring: Original program: Making changes: More changes: Cost of change increases rapidly! 14Friday, 9 December, 11
  • Refactoring visualized Without refactoring: With refactoring: Original program: Making changes: More changes: Cost of change increases rapidly! 14Friday, 9 December, 11
  • Refactoring visualized Without refactoring: With refactoring: Original program: Small change Making changes: More changes: Cost of change increases rapidly! 14Friday, 9 December, 11
  • Refactoring visualized Without refactoring: With refactoring: Original program: Small change Making changes: More changes: Cost of change increases rapidly! 14Friday, 9 December, 11
  • Refactoring visualized Without refactoring: With refactoring: Original program: Small change Refactor Making changes: More changes: Cost of change increases rapidly! 14Friday, 9 December, 11
  • Refactoring visualized Without refactoring: With refactoring: Original program: Small change Refactor Making changes: More changes: Cost of change increases rapidly! 14Friday, 9 December, 11
  • Refactoring visualized Without refactoring: With refactoring: Original program: Small change Refactor Making changes: Etc More changes: Cost of change Cost of change increases rapidly! not increases 14Friday, 9 December, 11
  • Refactoring based on unit testing 15Friday, 9 December, 11
  • What to refactor? 16Friday, 9 December, 11
  • Beware of blocking • Individual Code Ownership? • Branching for long time? • Deadline pressure? - Refactoring makes your code base easier to work on 17Friday, 9 December, 11
  • Time consuming? Too busy fire fighting, but no time to write tests? 18Friday, 9 December, 11
  • Sustainability Traditional Speculate Code Test Debug developmentTime vs 19Friday, 9 December, 11
  • Time developers do not notice Sustainability nor plan for Traditional Speculate Code Test Debug developmentTime vs 19Friday, 9 December, 11
  • Time developers do not notice Sustainability nor plan for Traditional Speculate Code Test Debug developmentTime vs Test-driven Spec Test and Code Debug development ulate 19Friday, 9 December, 11
  • Sustainability Traditional Speculate Code Test Debug developmentTime vs Feels slower Test-driven Spec Test and Code Debug development ulate 19Friday, 9 December, 11
  • We are tired of delivering craps Do you have confidence with your work before you deliver it? 20Friday, 9 December, 11
  • Edsger Dijkstra “Those who want really reliable software will discover that they must find means of avoiding the majority of bugs to start with, and as a result, the programming process will become cheaper. If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with.” 21Friday, 9 December, 11
  • TDD Cycle Test Implement Design • Short • Rhythmic • Incremental • Design-focused • Disciplined 22Friday, 9 December, 11
  • Oh, Our code was there already 1. Identify change point 2. Find test points 3. Break dependencies 4. Write tests 5. Make changes and refactor It is always harder to write unit tests after we wrote the code 23Friday, 9 December, 11
  • Our code is too simple, so we don’t need unit testing Our code is too complicated, so writing unit tests is too difficult We don’t have problems at unit level 24Friday, 9 December, 11
  • Tests you write after the fact are Defense or Justification • Test later = Test never • After-the-fact tests are written by someone who is already vested in the code and already knows how the problem was solved • There’s just no way those tests can be anywhere near as incisive as tests written first • If you write the unit test after the fact, you are not going to catch many bugs. 25Friday, 9 December, 11
  • Unit test is not just about testing Look at the design through unit tests 26Friday, 9 December, 11
  • Modularity == Testability Focus on tests first ensures modularity and other good design principles 27Friday, 9 December, 11
  • Design from the perspective of use rather than implementation 28Friday, 9 December, 11
  • It is always harder to write unit tests after we wrote the code • Debug-later-programming don’t consider testability in the first place • TDD guarantees testability, while you still need to know good design principles • Unit tests give you a safety net to try different design 29Friday, 9 December, 11
  • When you find it hard to write unit tests... • Instantiating class instance that is hard to setup? - What about using Factories? - Have you think about Dependency Injection? • Long methods? - Does it have more than one responsibilities? • Bare classes? - Why not provide abstract base classes to support better mocking? - Why clients need to know everything from this base class? • Interface Segregation Principle 30Friday, 9 December, 11
  • TDD, The Professional Option • Confidence and trust in the code - Treading the happy path - “If it doesn’t have to work, I can get it done a lot faster!” - “Cost of bug fixing is lower if it is found earlier” • Encourages good design - Clean it up later - Experimenting different design • Integration Testing - Making assumptions explicit 31Friday, 9 December, 11
  • Resources 32Friday, 9 December, 11
  • Agile Tour ShenZhen • Tencent Building, Shenzhen ( - 20 Nov 2011 - Tencent Building, Kejizhongyi Avenue, Hi-techPark,Nanshan District,Shenzhen. - 腾讯 侧 • http://www.agiletour.cn • Contact: steven@odd-e.com 33Friday, 9 December, 11
  • I want to organise a group in Hong Kong! http://tinyurl.com/HKALSDN 34Friday, 9 December, 11
  • Further readings • Integration Tests are a Scam: - http://www.jbrains.ca/series/integrated-tests-are-a-scam • Integration Contract Tests: - http://martinfowler.com/bliki/IntegrationContractTest.html • Opportunistic Refactoring: - http://martinfowler.com/bliki/OpportunisticRefactoring.html • Demand Technical Excellence: - http://www.renaissancesoftware.net/files/sglon/ LondonScrumGathering-v1r0.key.pdf • Clean Coder, by Robert Martin 35Friday, 9 December, 11
  • Books - Technical Practices 36Friday, 9 December, 11
  • Thank you :-) Steven Mak Email: steven@odd-e.com 37Friday, 9 December, 11