3. Myth 1: Why UT?
Unit Testing Is About Finding Bugs
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
6. Tips
● You don't 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. Myth 2: What to Test?
UT tests the user requirement
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. Internal Quality vs. External Quality
Unfortunately, internal quality is very often not directly linked with current
external quality.
10. UT is more about internal quality than external quality.
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. 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. Myth 3: Where to put the
focus?
Let's add UT, but don't touch the code
14. you want your good things in your
product, not somewhere else.
Not even in the tests.
15. Tips
● Don't 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. 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. Big, end to end test
Oh, shoot! I
climbed the
wrong rock.
22. Tips
● Testability is the key
● Challenge your team to have SOLID design
● Don't always have all dependent tests
23. Myth 5: Who Test?
By different person/team
Is a separate task
24. ● Because they are more likely to break the software?
○ That's simply a waste of time
● If they made a wrong design, they can not find it through
UT
○ Yes, that is simply true.
25. Test Example
test_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,
it's a design problem.
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. Myth 6: When?
Let's add UT later
writing code with unit tests takes much more time
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. 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. 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. 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?