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
We know the client code will be easy to use, because we drove the code based on the client itself!
We have tested the code as thoroughly as we can using unit tests.
We have kept the unit tests as an artifact of the coding effort so that we can continually re-run the tests as needed.
Code usage is already documented for our customers!

Gain #2: We will feel confident making changes to the code
If we make a change to this code, we can re-run the unit tests to verify if the code is still functionally correct - instantly!
We don’t have to fear the major changes that will likely be made later.
Because what is the one constant in software development? CHANGE.

dpuint offers some enhancements over FlexUnit that you might find valuable. The key differences are:
Better asynchronous support
Sequencing tests
Cairngorn tests
Highly recommended if you want to test UI.
A Newer Flex Testing Framework: dpuint

Questions?

Test-Driven Development

by EffectiveUI on Nov 02, 2011

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Test-Driven Development Presentation Transcript