Misconceptionsof Unit Testing

by Terry.YinZhe@gmail.com

for Scrum Gathering Shanghai 2011

twitter: @terryyinSina 微博:＠terry尹哲

Question: Which is likely to be the logo for unit testing?

Myth 1: Why UT?

Unit Testing Is About Finding Bugs

● 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

Unit Test

Then, why do we do UT?

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.

Myth 2: What to Test?

UT tests the user requirement

● 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?

Internal Quality vs. External Quality

Unfortunately, internal quality is very often not directly linked with current external quality.

UT is more about internal quality than external quality.

● 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)

Tips

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.

Myth 3: Where to put the focus?

Let's add UT, but don't touch the code

you want your good things in your product, not somewhere else.

Not even in the tests.

● 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

Tips

Myth 4: How to Test?

UT cases are fragile when I do an architectural change.

Comprehensive System (or functional) Regression test can replace UT

Big, end to end test

Oh, shoot! I climbed the wrong rock.

you can't be more stable than your dependencies

So, it's time to break the dependencies.

Example

Good unit test has very limited scope

● Testability is the key● Challenge your team to have SOLID design● Don't always have all dependent tests

Tips

Myth 5: Who Test?

By different person/team

Is a separate task

● 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.

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, it's a design problem.

● 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.

Tips

Myth 6: When?

Let's add UT later

writing code with unit tests takes much more time

Well, talk to him about your idea.

● Michael Feathers' definition for legacy code.● If you find yourself in a hole, what is the first thing to do?

● Test later = test never

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.

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.

● '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?

Tips

It's software design, after all.

Thanks to

Gerard Meszaros for reviewing my slides during Scrum Gathering Shanghai 2011.