1. TDD Unit tests from a slightly different point of view Katie Dwyer

2. About me... ● My favorite topic ● Bachelors and Masters degree in CS from NKU ● Occasionally teach Intro to OOP at NKU ● Yeah, not a big fan of change ● Got into Agile in October 2010 ● CSM, CSD, working on PMI-ACP ● Consultant for Sogeti, working as Release Manager for SAP Mobile at Cintas ● On Sogeti's Agility Council

3. On the Agenda ● Wait, what are you talking about? ● Developers either love TDD or hate it, why? ● Why bother? ● How do I start? ● You're only as good as your tests ● Tips

4. Wait, what are you talking about?

5. What in the world is TDD? ● Test-Driven Development ● Testing Drives Development (duh) ● Not a testing technique! ● Programming technique associated with Agile/XP

6. That didn't answer my question For every code change: 1. Write a unit test that fails 2. Change the code just enough that your test passes 3. Verify that rest of the tests pass Refactor if needed and make sure all the tests still pass

7. Goals of TDD ● Clean code that works ● Simplicity – maximize the work not done ● KISS – Keep It Simple Stupid

8. So, what's the difference between TDD and Unit Tests? ● You can have unit tests without doing TDD ● You can't do TDD without unit tests ● With TDD, you should have unit tests for all your code.

9. In TDD, unit tests are tools for development, not afterthoughts.

10. So TDD gives you the benefits of Unit Testing too ● Prove code works ● Changes don't break other code ● Testable code is well-designed code ● “Cover and modify instead of edit and pray” - Michael Feathers

11. Developers either love TDD or hate it, why?

12. Because they hate unit tests.

13. Different Mindset ● Live for today without planning for the future ● Maximizing the work not done ● A lesson from my daughter

14. Thanks, Ally

15. Challenges ● Takes longer, especially at first ● Misunderstandings – doesn't replace QA or User Acceptance testing, not a silver bullet ● Code coverage, do I really have to write a unit test for everything? ● Some languages are harder than others, but that means some are easier! ● Sometimes it's harder to write the test than it would be to just make the code change

16. Really, a second slide of challenges?!? ● Legacy code ● Yes, it gets its own slide

17. And Another on Legacy Code ● Can be daunting and intimidating ● Design may not be unit test friendly ● Changes are often to existing code rather than new classes/methods ● Anything that needs to be modified should be refactored to add unit tests ● Far slower than TDD with new code

18. Why Bother? ● Disciplined – focus on quality ● Demonstrate progress ● Lots of refactoring leads to better design ● You can refactor with higher confidence because you have unit tests ● You should have a high percentage of unit test coverage

19. Oh yes I did drag this out to two slides ● KISS again...less code means less complexity and less bugs ● Bugs are found earlier when they are less expensive to fix ● Nobody breaks your stuff without you knowing

20. OK, you've convinced me... How do I start?

21. Unit Test Library ● Select an appropriate unit test library for the language you are using ● Familiarize yourself with the unit test library ● If you are doing TDD with legacy code, code yourself up a toy application using TDD for practice

22. A journey of a thousand miles begins with a single step, and an application of a thousand lines should begin with a single test.

23. So just do it already ● Writing the test is often the hard part ● Every logic piece should have a unit test ● You must write a unit test before every code change

24. Testing Drives the Development ● Write a test for the change you need to make that you expect to fail ● Verify it fails (don't laugh, it happens) – It's okay if doesn't even compile ● Make the code change to make the test pass ● Verify the rest of the tests pass ● Look around and see if you should refactor ● Make sure all the tests still pass after you refactor

25. You're only as good as your tests...

26. Each unit test should ● Test one logical piece ● Document correct behavior ● Run fast ● Localize problems

27. Characteristics of Good Unit Test ● A single unit test should not verify too much functionality ● Unit tests should be independent from each other ● Unit tests shouldn't be heavily dependent on interface

28. Structure ● Setup ● Invoke what you are testing ● Verify your results ● Clean up

29. What should “a unit test” test? ● Good data => Good output ● Bad data => Expected output ● Boundary conditions ● Nulls ● Branches

31. Unit Test Tips ● Use dummy/mock objects ● Minimize assumptions ● Don't hard-code values ● Starting is the hardest part. ● Don't get discouraged!

32. Mock Objects ● Mimic complex object ● Stand in for real objects ● Same interface as real object ● Simple example: – Test client side logic – A large complex method has a piece that checks permission by hitting the server – Mock out the piece that checks permission and return what you need

33. Legacy Code Tips ● Add unit tests to document expected behavior as you go ● You can add the unit test and see why it fails and then modify the unit test to pass ● Add unit testing as you go to anything you modify ● Don't try to go back and add unit tests all at once

34. Refactoring Tips ● Use a tool with support! ● Goals – Reduce dependencies – Introduce seams ● Extract small pieces you understand first ● Divide into logical pieces ● Look for code smells

35. Code Smells ● Duplicated Code ● Long methods ● God object ● Feature envy ● Inappropriate Intimacy ● Lazy ● Contrived Complexity ● Long identifiers

36. Q & A

37. Thank you!!!