Is this how you hate unit testing?

Download Is this how you hate unit testing?

Post on 25-Jan-2015

1.142 views

Category:

Technology

1 download

Embed Size (px)

DESCRIPTION

 

TRANSCRIPT

  • 1. www.odd-e.comI hate unit testing!!!Friday, 9 December, 11

2. 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 3. 3Friday, 9 December, 11 4. I HATE UNIT TESTING! Doesnt catch many bugs Still need to do integration tests Waste time4Friday, 9 December, 11 5. Need to test at integrationlevel anyway? Is this what you mean by integration testing? 5Friday, 9 December, 11 6. How many tests do you need to cover through system level tests? 10 statesTests5 interactions5 interactions10 5 interactions10statesstates 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/les/sglon/LondonScrumGathering-v1r0.key.pdfFriday, 9 December, 11 7. 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 failures7Friday, 9 December, 11 8. Test Automation PyramidYou are going to need some integration tests,but not in the way you do like unit tests.8Friday, 9 December, 11 9. Write good focused unit tests Dont test the platform. When writing a single object to test with othercollaborating objects, use interfaces for thoseother points. Interfaces are not the actualcollaborating object. Leverage the interfaces so you dont need toactually test the other objects. Test the single object to speak to itself, i.e.State Tests Create your focused Collaboration andContract Tests.http://b-speaking.blogspot.com/search/label/integration%20tests9Friday, 9 December, 11 10. 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 11. Example:We are assuming that@Test compareTo() would return 1public void with_arguments(){ if we pass in Test! MyCollaborator c = mock(MyCollaborator.class);! when(c.compareTo("Test")).thenReturn(1);! assertEquals(1,a.doSomethingElse("Test"));}@Testpublic 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 bestable. Often running just once a day is plenty11Friday, 9 December, 11 12. Refactoring?Code smells!Code stinks!Its no fun writing unit test if you dont spend time refactoring 12Friday, 9 December, 11 13. Why? How? opportunity for refactoringamount of code smellsO indicatesmotivation developersO amount of badcodequick hacks# of bugs panic time spend onbug xing13Friday, 9 December, 11 14. Refactoring visualizedWithout refactoring:Original program:Making changes: More changes: 14Friday, 9 December, 11 15. Refactoring visualizedWithout refactoring:Original program:Making changes: More changes: 14Friday, 9 December, 11 16. Refactoring visualized Without refactoring:Original program:Making changes: More changes: Cost of change increases rapidly! 14Friday, 9 December, 11 17. Refactoring visualized Without refactoring: With refactoring:Original program:Making changes: More changes: Cost of change increases rapidly! 14Friday, 9 December, 11 18. Refactoring visualized Without refactoring: With refactoring:Original program:Small changeMaking changes: More changes: Cost of change increases rapidly!14Friday, 9 December, 11 19. Refactoring visualized Without refactoring: With refactoring:Original program:Small changeMaking changes: More changes: Cost of change increases rapidly!14Friday, 9 December, 11 20. Refactoring visualized Without refactoring: With refactoring:Original program:Small changeRefactorMaking changes: More changes: Cost of change increases rapidly!14Friday, 9 December, 11 21. Refactoring visualized Without refactoring: With refactoring:Original program:Small changeRefactorMaking changes: More changes: Cost of change increases rapidly!14Friday, 9 December, 11 22. Refactoring visualized Without refactoring: With refactoring:Original program:Small changeRefactorMaking changes: Etc More changes: Cost of change Cost of change increases rapidly! not increases14Friday, 9 December, 11 23. Refactoring based on unit testing 15Friday, 9 December, 11 24. What to refactor? 16Friday, 9 December, 11 25. 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 26. Time consuming?Too busy re ghting, but no time to write tests?18Friday, 9 December, 11 27. Sustainability Traditional Speculate Code Test DebugdevelopmentTime vs 19Friday, 9 December, 11 28. Time developersdo not notice Sustainabilitynor plan for Traditional Speculate Code Test DebugdevelopmentTime vs 19Friday, 9 December, 11 29. Time developers do not notice Sustainability nor plan for Traditional SpeculateCode Test DebugdevelopmentTime vs Test-driven SpecTest and CodeDebugdevelopmentulate19Friday, 9 December, 11 30. Sustainability Traditional SpeculateCode Test DebugdevelopmentTime vs Feels slower Test-driven SpecTest and CodeDebugdevelopmentulate19Friday, 9 December, 11 31. We are tired of delivering craps Do you have condence with your work before you deliver it? 20Friday, 9 December, 11 32. Edsger Dijkstra Those who want really reliable software will discover that they must nd 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 33. TDD CycleTest Implement Design Short Rhythmic Incremental Design-focused Disciplined22Friday, 9 December, 11 34. Oh, Our code was there already1. Identify change point2. Find test points3. Break dependencies4. Write tests5. Make changes and refactor It is always harder to write unit tests after we wrote the code 23Friday, 9 December, 11 35. Our code is too simple,so we dont need unit testingOur code is too complicated,so writing unit tests is too difcult We dont have problems at unit level24Friday, 9 December, 11 36. Tests you write after the fact are Defense or Justication 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 solvedTheres just no way those tests can be anywhere near as incisive as tests written rst If you write the unit test after the fact, you are not going to catch many bugs. 25Friday, 9 December, 11 37. Unit test is not just about testing Look at the design through unit tests 26Friday, 9 December, 11 38. Modularity== Testability Focus on tests rst ensures modularityand other good design principles27Friday, 9 December, 11 39. Design from the perspective of userather than implementation 28Friday, 9 December, 11 40. It is always harder to write unit testsafter we wrote the code Debug-later-programming dont consider testability in the rst place TDD guarantees testability, while you still need to know good design principlesUnit tests give you a safety net to try different design 29Friday, 9 December, 11 41. When you nd 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 42. TDD, The Professional OptionCondence and trust in the code- Treading the happy path- If it doesnt have to work, I can get it done a lot faster!- Cost of bug xing is lower if it is found earlierEncourages good design- Clean it up later- Experimenting different designIntegration Testing- Making assumptions explicit31Friday, 9 December, 11 43. Resources 32Friday, 9 December, 11 44. 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.com33Friday, 9 December, 11 45. I want to organise a group inHong Kong! http://tinyurl.com/HKALSDN34Friday, 9 December, 11 46. 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/les/sglon/LondonScrumGathering-v1r0.key.pdf Clean Coder, by Robert Martin35Friday, 9 December, 11 47. Books - Technical Practices 36Friday, 9 December, 11 48. Thank you :-) Steven Mak Email: steven@odd-e.com 37Friday, 9 December, 11