Test Driven Development Introduction

Test Driven Development
Introduction

Issued date: 8/29/2007
Author: Nguyen Phuc Hai

Agenda

Introduction


Unit test overview


Refactoring


Test Driven Development approach


Q&A


Trainer’s profile

Over seven years experienced in software

industry on both product development and
out-sourcing.
Hand-over various positions from developers,

technical lead, project manager, technical
architecture and program/product managers.

Trainer’s profile (cont.)

Be experienced in managing small, medium

and large projects/program – Took oversight
more than 100 associates in one of the
biggest account in company
Be experienced on technical design,

technical management in various sizes of
projects from small to enterprise applications
on both desktop and web environment

Trainer’s profile

Be recognized as an Agile expert that has

experienced in managing Agile process,
applying Agile practices.
Maintain the blog that share experienced in

software development on both technical and
management areas (http://
www.haiphucnguyen.net/blog/)

Unit test - FAQs

Check the link for some common concerns of

applying unit test and its benefits:
http://www.haiphucnguyen.net/blog/?p=40

Unit test best practices

Keep test method as simple as possible:

DRY principle (Don’t repeat yourself)
–

Re-use test set up across test cases: put non-
–
trivial test data in test set up method
Clean test code as productive code
–

Evident data


All non-trivial methods must be passed unit

test with 100% coverage ratio.


Unit test independent with:

Other unit tests, order of unit test running
–

Environment (operating system, hardware
–
configuration, database …)
Fix broken test as soon as possible (it should

be immediately)
After fixing defect, write unit test to prevent it

re-occur


All test cases must be passed at the end of

working day.
Test project code, not library code


Minimal maintenance of test code


If you can not write unit test for some

functionality that means your code has
problem! Refactor it immediately

How to make code becomes testable

Using interface in communication among

layers, modules.
Dependency injection


Dependency lookup


Methods/Constructors has as less

parameters as possible (4 is the best
number)

How to make code becomes testable

Class is not depended in many other classes

-> it is hard to initiate instance of this class
One method has only one purpose


Be careful with singleton class or static

methods!
And the most important: refactoring your

code if it is not testable (esp. legacy code)

Refactoring

Refactoring is a disciplined technique for

restructuring an existing body of code,
altering its internal structure without changing
its external behavior. The system is also kept
fully working after each small refactoring,
reducing the chances that a system can get
seriously broken during the restructuring.

Refactoring (cont.)

Whenever you think you can make more

benefits with your new code:
Increase the re-usability
–

Make the code becomes testable
–

Avoid the rigid, fragile issues
–

Better performance
–

…
–

Refactoring – best practices

Keep small change running before proceed

another change.
Unit test should be written to make sure

refactoring does not change system’s
behaviors.
To legacy system: write test first, refactoring

and verify result

Test Driven Development

TDD is a technique to improve the quality of

both code and design. Developers will write
the test first, then writing the code to make it
pass the test. They can refactor code to
avoid issues (duplication or non-optimize
code …)

TDD benefits

Promoting high code coverage for productive

code.
Improving quality of architecture and code


Prevent defects cost is less than detect

defects cost

TDD Cycle

Prepare a list of test cases


Follow the TDD Rhythm:

Pick a test to implement
–

Write a fail test
–

Quickly make test green
–

Refactor to eliminate duplication
–

TDD – Things always do

Write test-first


Maintain to-do list


Writing new code only if there is failing

automated test
Run all tests all the time not only single

isolated test

TDD – Things always do

Job is done whenever complete

implementation and all test have green status

TDD – Things never do

Write test for trivial methods (such as

getters/setters)
Commit code with failed test


Big upfront design and code that makes test

first do not cover all cases of writing code

TDD best practices

Write the simple test first, then write code.

After that write test code for more complexity
functionality
Run test immediately whenever complete

writing code
If spending much time for writing code, break

the functionality into smaller ones and
applying TDD for these pieces

TDD best practices

Whenever test code or productive code

smells, refactor it immediately
After writing code, use coverage tool to make

sure productive code is covered 100% by
test method. If some piece of code is not
covered, your implementation has problem!
Use mock objects if needed


Tools support TDD

Various tools help developers easier to do

TDD:
IDE: Eclipse, MS Visual Studio Team System
–

Build tools: Ant, Maven, Nant
–

xUnit tools: Junit, TestNG, DBUnit, Nunit, …
–

Coverage tools: JCoverage, NCoverage
–

TDD examples

A user story of login page:

Presentation Layer: Login.html, Login.java
–

Service Layer: LoginService.java
–

Data Access Layer: LoginDAO.java
–

More complex user story: applying acegi for

authentication – authorization process:
Re-factor LoginService.java
–

Run test again
–

TDD examples (cont.)

Write the mock up html file: Login.html


Write test class: LoginTest.java


Write test method for case user login

success:
@Test
Public void testLoginSuccess() {
….
}


Implement login function that pass the test

Void onSubmit() {
if (username.equals(“VietNam”)) {
setResponsePage(Helloworld.class);
}
else {
form.error(“Login fail”);
}
}


Run LoginTest again and verify result (it has

green color)
Return the Login.java and add feature

verifying user base on database
Void onSubmit() {
if (userService.getUser(userName) != null) {
…
}
}


The enterprise application that maintains the

suite of test cases and number of test cases
is growing daily:
Automation unit test
–

Continuous Integration
–

Q&A

Any question of unit test, refactoring and

TDD is welcome 

Thank you

I hope you enjoy with this course. Any further

discussion, please contact me at
Email: hainguyen@esofthead.com
–

My blog: http://blog.esofthead.com
–

Test Driven Development Introduction

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Test Driven Development Introduction

Similar to Test Driven Development Introduction (20)

Test Driven Development Introduction