1 / 55

Agile Developers Go Testing Part II

Agile Developers Go Testing Part II. Darcy Casselman @ flying_squirrel Alexei Zheglov @az1. November 2010. What are we talking about today?. A lot of things… They may seem disconnected, but they all: improve software quality involve testing done by developers

paxton
Télécharger la présentation

Agile Developers Go Testing Part II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Agile Developers Go TestingPart II Darcy Casselman @flying_squirrel Alexei Zheglov @az1 November 2010

  2. What are we talking about today? • A lot of things… • They may seem disconnected, but they all: • improve software quality • involve testing • done by developers • None of them can do the job alone • We cannot: • Talk about all of them • Give them equal time

  3. Unit Testing • We showed you a very simple unit test example earlier • We’ll show you a more difficult example later • Let’s step back first

  4. Focus on Quality quotes "...in 2000, during the dot-com bubble, ... software quality for North American teams... ranged from 6 defects per function point to less than 3 per 100 function point, a range of 200 to 1.  The midpoint is approximately 1 defect per 0.6 to 1.0 function points.  This implies that it is common for teams to spend more than 90 percent of their effort fixing defects.” http://www.amazon.com/Kanban-David-J-Anderson/dp/0984521402/ http://www.amazon.com/Software-Assessments-Benchmarks-Best-Practices/dp/0201485427/

  5. Logical Connection? “The midpoint is approximately 1 defect per 0.6 to 1.0 function points.  This implies that it is common for teams to spend more than 90 percent of their effort fixing defects.” How does he know what they are spending their time on?

  6. Capacity Allocation To Fixing Defects

  7. = Capacity Allocation To Fixing Defects Defect Injection Rate

  8. Bugs, Features http://www.flickr.com/photos/dratz/1045336659/

  9. Another View • Root-cause analysis of established practices • E.g. unit testing • Five-whys applied to the solution, not the problem • The link between the third and fourth whys? Source: Karl Scotland http://availagility.co.uk/2010/10/04/a-root-cause-analysis-of-agile-practices/

  10. Compare Two Teams Team A Team B 10 features 8 bugs • Just finished 40 “features” (units of work) • Introduced 10 “bugs” (units of rework)

  11. Team A Progression • Terms beyond the first three are negligible • Most defects eliminated in the next 2 releases • The 2nd maintenance release scope is very small • Illusion that any team can do it • Time spent fixing defects: 25%

  12. Team B Progression • The sum of the first 3 terms: only 24.4 (less than half of the total!) • The sum of the first 10: approx. 45 • Time spent fixing defects: 80%

  13. We want to be more like Team A (or better) and certainly not like Team B

  14. Testing • Is what we are talking about today • Leaving out other technical practices • Remembering that testing itself does not provide quality

  15. Test Matrix

  16. Test Matrix

  17. Test Matrix

  18. Test Matrix

  19. Test Matrix

  20. Test Matrix

  21. Test Matrix Sources: Robert C. Martin, Rob Diana http://regulargeek.com/2009/06/12/how-much-testing-is-enough/

  22. Test Matrix Sources: Robert C. Martin, Rob Diana http://regulargeek.com/2009/06/12/how-much-testing-is-enough/

  23. Test Matrix Sources: Robert C. Martin, Rob Diana http://regulargeek.com/2009/06/12/how-much-testing-is-enough/

  24. A Very Short Introduction to Acceptance Testing

  25. Consider This Test Script • A new customer registers • The customer places three books in the shopping cart • The customer goes to check-out • The customer fills in their delivery address (province: Ontario) • The system offers free delivery to the customer Source: GojkoAdzic. Bridging the Communication Gap, pp. 78-79 http://www.amazon.com/gp/product/0955683610

  26. Compare the Test Script to This The system offers free delivery to Ontario customers when they place their first order and their order contains at least three books

  27. Convert to the Tabular Form

  28. How To Do It • Collaborate: • developers • business analysts • testers • product owner • Which tool to use is not as important • Don’t look up terminology in Wikipedia

  29. Books http://www.amazon.com/gp/product/0955683610 http://manning.com/adzic/

  30. Unit-TestingWhen System Under Test (SUT)Has Dependencies Break the dependencies

  31. What If We Don’t? • Configuration • Database data • Remote services • Permissions • Time to run • Infrequent errors • Dependencies in development

  32. Can You Run Unit Tests Like This? http://www.flickr.com/photos/theredproject/2878006012/

  33. Code Example Caller StudentRepository GradingEngine NotificationService

  34. Code Example Unit Test Stub System Under Test Mock

  35. (Open IDE)

  36. Source http://www.osherove.com/blog/2010/9/10/2010-poll-which-isolation-framework-do-you-use-in-net.htmlSeptember 2010

  37. Two Camps Design for Testability: Moq, RhinoMocks, etc. Mock Anything, e.g. Typemock Isolator, JustMock Rely on Profiler API Can intercept anything and run something else instead Can fake statics, sealed classes, etc. Don’t force design for testability • Dynamically fake objects implementing interfaces/base classes in their own way • Require software under test to be designed to be testable • Programmers to follow SOLID principles (esp. Dependency Inversion Principle)

  38. Popular Frameworks (Java) • “Conventional”: • Mockitohttp://code.google.com/p/mockito/ • EasyMockhttp://easymock.org/ • JMockhttp://www.jmock.org/ • Alternative: • JMockithttp://code.google.com/p/jmockit/

  39. Roy Osherove • The Chief Architect at TypeMock • Wrote: “A customer switches to Moq – and I’m happy” • And: “This is pure awesome. This is why I come to work every day.” • How is it possible? • Read it: http://www.osherove.com/blog/2010/9/29/a-customer-switches-to-moq-and-im-happy.html

  40. Back to Our Code Example • Grading engine operates on Student and Grade • But Student has a Department • And Grade has a Course and Course has a Semester • We start mocking • Soon, we have a lot of mocks

  41. “Every time a mock returns another mock a fairy dies” • Who said it? • Not the guy whose tweet comes up first in Google search results • I am not 100% sure • What the heck does it mean anyway?

  42. “Every time a mock returns another mock a fairy dies” • Who said it? • Not the guy whose tweet comes up first in Google search results • I am not 100% sure • What the heck does it mean anyway? • We don’t have time for it in this presentation

  43. http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627/http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627/

  44. Creating Objects • Constructor injection (as in our code example) • Factory • What if dependencies have dependencies? • What if dependencies of dependencies have dependencies?

  45. Pretty Soon, Things Begin To Look Like This (and this is a simple example) (different box color = different life span) Source: http://ayende.com/Blog/archive/2010/01/22/rejecting-dependency-injection-inversion.aspx

  46. These Tools Can Help • StructureMap • Castle Windsor • Unity • NInject • autofac

More Related