Test Driven Development

Test-Driven Development by John Blanco

The process of designing software by writing a validating client before the code. What is Test-Driven Development (TDD)? Maintaining an evolving set of unit tests that continuously validate the correctness (or not) of your code. What is Automated Unit Testing?

Automated Unit Testing != Test-Driven Development TDD is a way of thinking about your code, but it doesn’t require unit testing. That being said, you should write them if you can. Agile processes adapt to change. Unit tests help to manage change in our code. Unit Testing is a key component of the Agile Methodology

Dispelling Unit Testing Myths

No. Writing unit tests is an investment towards time savings over the lifetime of the project. Myth #1: Won’t writing unit tests double by development time?

We won’t need to constantly validate our code each time we make changes.

Finding the bugs early means far less time fixing them later.

If our unit tests are good, we won’t need to spend hours or days tracking down bugs in the most fundamental layers of our code.

No. Unit tests are not parallel to your code like documentation. You will be driving your code with them. Myth #2: Won’t all my unit tests just get out of date?

TDD is a programming paradigm.

Unit tests are not an artifact of your code. They represent how you write it!

However, if you don’t appreciate unit testing, they likely will not be worth the time to create.

No. The client is paying for clean, correct code. Unit testing is the means to that end. Myth #3: Won’t the client refuse to pay for it?

Do they pay us to test our code?

Do they pay us to use design patterns?

Do they pay us to use UML?

xUnit is the framework for automating our unit tests. Implementations exist for C++, C#, Java, PHP, Ruby, Python, Perl, Prolog, LISP, … and Flex! Created by Erich Gamma, member of the GoF and co-author of Eclipse JDT. Introducing xUnit!

FlexUnit is the Flex implementation of xUnit. FlexUnit

Tests you will be performing on your code:

assertEquals()

assertTrue()

assertNotUndefined()

assertStrictlyEquals()

…

Don’t worry. Chances are, you’re already writing unit tests! Whoa! Whoa! Hold On -- This Seems Excessive!

<mx:Application creationComplete=“onCreationComplete()”> <mx:Script> private function onCreationComplete():void { // DEVELOPMENT ONLY - REMOVE LATER var htmlMaker:MyHTMLMaker = new MyHTMLMaker(); htmlMaker.startTag(“b”); htmlMaker.addContent(“My bold text!!!”); htmlMaker.endTag(); trace(“RESULT: ” + htmlMaker.toString()); } </mx:Script> . . . </mx:Application> Ever Write Code Like This…And Then Delete It Afterwards?

Fool! The problem is that you’re not anticipating CHANGE. When that happens, you will need to modify and test your code all over again. What if we kept that test? Yes! And then once I verify it’s working, I remove it. So?

There are two ways we can organize our unit tests:

Inside the project

Outside the project

My personal preference is outside of the project. Here’s why:

Keeps our code and unit tests physically separate.

Avoids the double-build conundrum.

Allows us to close the unit test project when desirable.

Allows us to run tests against projects in multiple locations.

Setting Up Your Project For TDD http://raptureinvenice.blogspot.com/2008/04/better-way-to-set-up-flexunit.html Reference:

Create a Flex or AIR project. (e.g., twitterme)

Create a Flex or AIR unit testing project. (e.g., twitterme-tests)

Add twitterme/src to the source path of twitterme-tests.

Add a boilerplate TestRunner application to twitterme-tests.

Add flexunit.swc to twitterme-tests/libs.

Setting Up Your Project For TDD http://code.google.com/p/as3flexunitlib/ References: http://raptureinvenice.blogspot.com/2008/04/better-way-to-set-up-flexunit.html

Working Session

Wait! We Need a Change!

What Have We Accomplished?

Gain #1: We have a clean, stable piece of code