1 / 51

Under Test

Under Test. TDD Techniques from the Trenches May 24, 2011 Matt Thurston. Agenda. Rediscovery. Nutshell. Why get code ‘Under Test’?. Cost of Change. Change. Simple Code Change (“Hack”) versus Tough Design Change (“Right Thing”). Technical Debt. Motivator. What is Legacy Code?.

lenci
Download Presentation

Under Test

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. Under Test TDD Techniques from the Trenches May 24, 2011 Matt Thurston

  2. Agenda

  3. Rediscovery

  4. Nutshell

  5. Why get code ‘Under Test’?

  6. Cost of Change

  7. Change Simple Code Change (“Hack”) versus Tough Design Change (“Right Thing”)

  8. Technical Debt

  9. Motivator

  10. What is Legacy Code? • Inherited? • Old version? • Previous platform? • ‘C’?

  11. Legacy Code = Code Without Tests

  12. Confident Change • Changing legacy code • What will break? • Will we find the break?

  13. Under Test • TDD Greenfields vsLegacy Code Retrofits

  14. Defining ‘Unit Test’ • Our Unit is the C++ class • Unit Tests in C++

  15. Issue #1 • TDD requires immediate feedback

  16. What should CTRL + B do? • Build and test as much as possible within a few seconds.

  17. Deployment Fidelity

  18. Deployment Fidelity • Deployment Fidelity typically dictates Test Fidelity

  19. Test Fidelity

  20. Test Fidelity

  21. Introduce New Fidelity? • TDD requires immediate feedback • If necessary, introduce a new fidelity

  22. Issue #2 • ‘Random’ test failures

  23. Dependency Inversion • E.g. • Foo uses files to store configuration information • Instead, inject FooConfiguration with • Virtual boolFooConfiguration::isEnabled() = 0;

  24. Dependency Inversion • Big Benefits: • Improves isolation • Simplifies reasoning about collaborations

  25. Issue #3 • Difficult component

  26. Difficult Components • Lack of modularity • Lots of dependencies • Lack of coherent design • Full of bugs • Etc.

  27. Integration Test First • Works well for Difficult Components • Provides confidence when re-factoringfor unit testability

  28. Issue #4 • Getting inherited legacy code under test

  29. Characterization Tests

  30. Characterization Tests • Capture reality not expected behavior • The first test is the hardest

  31. Failing a Unit Test • If a unit test has never failed once, how do you know it works?

  32. Mutation Testing

  33. Mutation Testing

  34. Semantic Memory

  35. Tests are never wrong • Tests encode semantics of the software • (even if the sematic is wrong)

  36. Comment on comments • “When the code and the comments disagree, both are probably wrong.” – Norm Schryer

  37. Under Test vs. Coding Speed

  38. Dreaming of Code

  39. Continuous Testing • Share tests • Don’t let test code rot • Integrate with build / CI tool

  40. Mocks, Stubs, Fakes • Take care with terminology overloading

  41. Mocks, Stubs, Fakes • Take care with terminology overloading • Mock: • Object used to mock collaborator behavior in a unit test • Stub: • Satisfies linkage from a collaborator, provides no implementation (e.g. asserts) • Fake: • Implements a collaborator’s functionality in a synthetic fashion

  42. Not Just the Tests • Code coverage • Static analysis (e.g. Lint, -Wall) • Dynamic analysis (e.g. valgrind)

  43. Quality? • TDD / Unit Testing does not imply Quality

  44. Questions? Comments?

More Related