Software Design Guided by Tests

This presentation is based on the excellent book "Growing Object-Oriented Software, Guided by Tests". The key points in this deck discuss the importance of tests as related to software design.

Transcript

1. Software Design Guided by Tests Using Testing for Feedback
2. Writing tests is a design activity “…it specifies each requirement in the form of an executable example that can be shown to work.” – Pryce, et. al
3. Testing Reveals Design Flaws public  void  testDogWagging()  {    dog.getBody().getTail().wag();    assertTrue(dog.isHappy());   }   public  void  testDogWagging()  {    dog.expressHappiness();    assertTrue(dog.isHappy());   }   Law of Demeter
4. Testing Practices That Support Change Unit Testing   TDD, BDD, Mocks   Do our objects do the right thing, are they “easy” to use? Integration Testing   Stubs, Fakes   Does our code work against code we can’t change? End to End Testing   Live systems   Database level Functional Testing   Acceptance   Exercise system logic   Does the whole system work?
5. Your System
6. Unit Testing is Testing in Isolation mocks TEST
7. Unit Testing will verify… State   Inspect primary object’s state for expected results   Verify state of collaborators Behaviour   Isolate SUT from collaborators   Verify collaborator reactions
8. Test Doubles Dummy   Place holders   Statics Stub   Canned responses   Stateful Mock   Pre-programmed expectations   Sequential Fake   Partially working   Impersonates
9. TDD in Practice Write  a  failing   unit  test   Make  the   test  pass   Refactor   Design
10. Testing with DSL in Mind   Code should express its behaviour at the level of a shared language   Use matchers to build up the domain language   Testing has its own “language”   assertThat(theCookie,  is(myCookie);   Programs must be written for people to read, and only incidentally for machines to execute. - Abelson & Sussman
11. Testing Should be Expressive
12. expressive Tests that are reveal intention and provide insight into design decisions.
13. Listen to Your Tests   Readable and informative tests prevent brittleness   “Test Smells” are symptoms of design flaws   Too many mock objects   Lengthy, vague expectations   Needing to mock out private functions   Excessively complex matchers   If a test is difficult to write, it is sometimes good to ask why is it difficult
14. References