Misconceptions Of Unit Testing


Published on

This is my slides used in Scrum Gathering Shanghai 2011.

1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Misconceptions Of Unit Testing

  1. 1. Misconceptionsof Unit Testingfor Scrum Gathering Shanghai 2011by Terry.YinZhe@gmail.com twitter: @terryyin Sina 微博:@terry尹哲
  2. 2. Question: Which is likely to be the logo for unit testing?
  3. 3. Myth 1: Why UT?Unit Testing Is About Finding Bugs
  4. 4. ● People are told that UT can help them find a lot of bugs ○ This is a common reason why people stop doing UT after a few months. ○ And this is why management stop believe in UT too.● Build and fix vs. Prevent from having bugs
  5. 5. Then, why do we do UT? Unit Test
  6. 6. Tips ● You dont want the team to generate buggy code in the first place. ● You want the code to be protected for implementing your future ideas, and still keep productive in the future. ● Tell your team that they will sleep better when they know that their source code are protected by UT.
  7. 7. Myth 2: What to Test?UT tests the user requirement
  8. 8. ● Most people (including and especially PO) care more about ○ Is my software functioning as per the requirement?● But in the same time, they could omit ○ Does my software have a good internal design?
  9. 9. Internal Quality vs. External QualityUnfortunately, internal quality is very often not directly linked with currentexternal quality.
  10. 10. UT is more about internal quality than external quality.
  11. 11. Tips● The main purpose of UT is not to cover your system requirement● The internal quality is as important as external quality ○ Good design (testable design)
  12. 12. UT is duplication ● Well, yes. ● As the RAID system in computer system, double entry book keeping in accounting, extra protections in rock climbing, UT is a necessary redundancy in programming.
  13. 13. Myth 3: Where to put the focus?Lets add UT, but dont touch the code
  14. 14. you want your good things in yourproduct, not somewhere else.Not even in the tests.
  15. 15. Tips● Dont force your team to test badly designed code ○ Ask them to make it testable first.● "Complex" test framework and tests do not always mean good thing. ○ You want great product, not great UT ○ Nor great document
  16. 16. Myth 4: How to Test? UT cases are fragile when I do an architectural change.Comprehensive System (or functional) Regression test can replace UT
  17. 17. Big, end to end test Oh, shoot! I climbed the wrong rock.
  18. 18. you cant be more stable thanyour dependencies
  19. 19. So, its time to break the dependencies.
  20. 20. Example
  21. 21. Good unit test has very limited scope
  22. 22. Tips● Testability is the key● Challenge your team to have SOLID design● Dont always have all dependent tests
  23. 23. Myth 5: Who Test?By different person/team Is a separate task
  24. 24. ● Because they are more likely to break the software? ○ Thats simply a waste of time● If they made a wrong design, they can not find it through UT ○ Yes, that is simply true.
  25. 25. Test Exampletest_is_able_to_chow([2, 3], 1);test_is_able_to_chow([2, 3], 4);test_is_able_to_chow([1, 3], 2);test_is_not_able_to_chow([1, 4], 2);test_is_able_to_chow([1, 2, 3], 2);test_is_not_able_to_chow([1], 2); This is not a test problem, its a design problem.
  26. 26. Tips● Just let people who do the design to write the protection of their design● UT should be a natural part of coding● Nothing can replace domain knowledge or 10- year experience ○ No silver bullet.
  27. 27. Myth 6: When? Lets add UT laterwriting code with unit tests takes much more time
  28. 28. Well, talk to him about your idea.
  29. 29. ● Michael Feathers definition for legacy code.● If you find yourself in a hole, what is the first thing to do?● Test later = test never
  30. 30. Debug vs. Precise/immediate Failure Report These cases, they are more meaningful when they pass. These cases, they can tell us a lot of useful information when they fail.
  31. 31. 8 shames, 8 honors以动手实践为荣,以只看不练为耻。 以打印日志为荣,以单步跟踪为耻。以空白分隔为荣,以制表分隔为耻。 以单元测试为荣,以手工测试为耻。 以代码重用为荣,以复制粘贴为耻。 以多态应用为荣,以分支判断为耻。 以短小精悍为荣,以冗余拖沓为耻。 以总结思考为荣,以不求甚解为耻。 Honor for get your hands dirty, shame for just watching. Honor for logging, shame for debugging. Honor for indenting with spaces, shame for using tabs. Honor for unit testing, shame for manual testing. Honor for code reusing, shame for copy-paste. Honor for polymorphism, shame for using ifs. Honor for short and neat, shame for tediousness. Honor for summarizing and thinking, shame for superficial understanding.
  32. 32. Tips● time to find the bug and time to locate the bug are the keys to productivity.● Any other task will look more important to you than adding UT in the future.● It is suppose to be faster to do the UT while coding. ○ Are you making the problem better or worse?
  33. 33. Its software design, after all.
  34. 34. Thanks toGerard Meszarosfor reviewing my slides during Scrum Gathering Shanghai2011.