1. Effective TDD
Less is More
Ben Lau
2013

2. Conversation with a
programmer using TDD
Story (1)

3. “TDD is really excellent”
“It helps me to fix a lot of bug
and speed up the development”
The programmer said

4. Then the programmer ask
Can I ask QA to
write more test
code for me?

5. TDD is Test Driven
Development
But it is NOT asking you to
write a lot of test code

6. How deep are your unit tests?
“I get paid for code that works, not for tests, so my philosophy is
to test as little as possible to reach a given level of confidence (I
suspect this level of confidence is high compared to industry
standards, but that could just be hubris). If I don't typically make
a kind of mistake (like setting the wrong variables in a
constructor), I don't test for it. I do tend to make sense of test
errors, so I'm extra careful when I have logic with complicated
conditionals. When coding on a tea...” [snipped]
by Kent Beck
The creator of TDD
A post in stackoverflow
Source: http://goo.gl/WRmWa

7. Why we don't write test case
“It is too early! Do it when the project finished!”
“It is working. We don't need test program”
“Let's QA do it!”
“Testing is not real work.”
About 261,000,000 results (0.55 seconds)

8. At the end , you won't write any testing code
Source : http://goo.gl/cNTmo

9. In my opinion...
We don't write test code
just because...
It is not funny

10. Writing test code is boring and useless?
“I have confidence with my code,
why need to write extra code to
prove it work and the result is
just to print “OK”?”
“It is just wasting of time. ”

11. However , it is not rare
Automated testing code is necessary but people hate it
Source: http://goo.gl/4QrBD

12. Make it fun by make it fail
Enjoy writing testing code – Tip 1

13. Story (2) – Pair programming
Mission
Refactor the program with test code
due to requirement changes

14. The conversation
Ben : “So this piece of code is wrong?”
Programmer: “NO! It is correct.” (before
requirement change)
Ben : “Nevermind. I will make it wrong no matter
is it working now. (smile)”

15. So make it fun by make it fail
1) Don't touch the main program
2) Modify the test code according to the
requirement changes
3) Run it

16. Expected result - Red Light
Compile error / throw undefined
exception
● If it is green (surprise!):
– Your test code is wrong?
● May be you have misunderstood the
requirement
– The code base has supported the
feature already?
● Finished!
– Someone disabled the test code?
● You find a potential problem

17. Your mission - turn it green
● The short term goal – Fix it.
● It is an achievement
● The definition of “Done” is
clear = Pass the test case.
● Highly focused on what you
are doing

18. Enjoy writing testing code – Tip 2
Design your program
by write test code first

19. Just write it?
● Many project / module start without design
documentation and lets programmer “just
write it”.
● Many programmers enjoy working in this
way (before the hell of integration and
testing)
● Sometimes may discover architectural
failure but it is already too late to fix

20. Design failure?
● Even you have design documentation
– It may not be deep enough
– It may be wrong
● In fact ,the specification / design document and
implementation can be different.
● Design failure is usually discovered in implementation
● Coding is the most effective way to discover design
failure , but the cost of change is very high

21. Design by writing test code
● Write test code before to implement the main program
● Just like writing pseudo code but executable
● Help you to clarify your intention
– How others use your module?
– Will it be confusing? Too ugly? Too complicated?
– Inconsistent with other module?
– Is it testable?
– Discover design failure by stand in the point of user without real
implementation.

22. Practice make perfect
var a = [3];
console.log(a.length); //
1
consloe.log(a[0]); //3
var a = new Array(3);
console.log(a.length); //
3
consloe.log(typeof
a[0]); //undefined
● A typical example
code in text book
● Expected output is
written in comment
● Verify the result by
human eye

23. Turn into test code is easy
test("array" , function() {
var a = [3];
ok(a.length == 1);
ok(a[0] == 3);
var a = new Array(3);
ok(a.length == 3);
ok(typeof a[0] ==
undefined);
});
● Describe your
expectation
(Specification / Design
plan)
● May discover potential
problem in this phase
http://goo.gl/9wiKD
All code examples are embedded
within a test framework

24. Less is more

25. Mission
● Implement an user account creation RESTful API but
no document and your boss ask you to do it now.
● It is coded before the real handling code
● Design during coding...
– The name of test case = mission statement
– Try to demonstrate a success and fail case...
– Th URL and method is “POST /account”
– The successful code should be 201 instead of 200
– Fail code : 400

26. exports.createAccount = function(test) {
// Mission: Implement an account creation call using node.js
var app = express();
app.use(express.bodyParser());
app.post("/account",account.create);
request(app) //"supertest" may simulate HTTP call to express
.post("/account")
.expect(400) // Argument mssing, it should return error.
.end(function(err,res) {
if (err) {test.ok(false,err)}
}); // A simple test case
request(app)
.post("/account")
.set( 'Content-Type', 'application/json' )
.send({ username : "tester" ,
email : "xxx@xxx.com" })
.expect(201) // Expected result
.end(function(err,res) {
if (err) {test.ok(false,err)}
test.done();
});
}

27. Tests Missed / Hidden Requirements
● Duplicated username and email ?
● Email format checking?
● Fields like birthday, age , gender?
● Verify database record?
● Verify the output content?
● The coverage of test is not 100%
● Create account is a simple task , 100% coverage of test
code may be 10 times more then the real implementation

28. You don't need 100% coverage in TDD
● 100% coverage of test is simply not possible in
many condition
● The more the coverage, the more the time
consumed. (Usually in exponential rate)
● But a simple success and fail condition is very
easy!
● TDD turn writing test into a design activity (funny)
but not asking to write a lot of test code (very
boring)

29. Write test code only if needed
● Example
– Design driven
● For new API of module
– Bug driven
● Do it when you got a bug report
● Prevent it happen again
● Enhance the coverage of test
– Complicated code and conditional

30. Conclusion

31. The core activity of TDD
● Write test code first
● Write failing test case

32. Write test code first
● It is not just to verify the work (boring)
● Force developer to clarify their intention
– What are you going to do?
– Verify the design - is it too tight or unfocused?
● You may discover design failure during coding
● If you have coded the feature , you may not want to change it
– Design code in testable way. More easy to debug and
extend
– Helping the team to understand the features

33. Write failing test case
● Set a short term goal : Make it pass (funny~)
● Limit the scope
● Concentrate your work

34. The benefit
● You have automated test codes!
● Your code is testable
● Testable code is more easy to debug and
change.
● “Programmers using pure TDD on new
("greenfield") projects reported they only rarely
felt the need to invoke a debugger”. Quoted
from Wikipedia

35. Thank you
Twitter: @benlaud