Why Test with FlexUnit?

Michael LabriolaDigital Primates

@mlabriola

Who are you?

Michael LabriolaSenior Consultant at Digital PrimatesFlexUnit 4 Architect/Lead DeveloperFan of Working Code

Are you a genius developer who writes perfect code without

mistakes?

80% of your time as a developer is spent identifying and

correcting defects.

Software mistakes cost the US Economy about 80 billion

dollars a year.

Half of that is absorbed by consumers.

The other half is absorbed by the software developers

Errors cost more to fix the later in the process they are found

An error found after release can cost 100x more to fix than during early development

The point is that we need to do a better job of finding errors and we need to find them sooner.

The problem: Software developers, myself included,

are hypocrites.

Developers will go out of there way to automate things.

We will spend time to automate code formatting and simple

code generation

But when it comes to debugging, something we spend 80% of our time doing, we choose to do that

manually

Why do you want to spend your time doing a repetitive task

that a computer can do for you?

What do you think happens to your desire and ability to test when time gets short on a

project?

How do we reverse this trend? How do we fix these issues?

In the beginner's mind there are many possibilities, in the expert's mind there are few

-- Shunryu Suzuki

We need to change our approach. We need to do what

we do best, automate.

Computers do repetitive tasks faster than we can. They also

don’t tire of doing so.

That means if we automate our tests, we can run them

continually.

Running tests continually means we find errors sooner. Finding errors sooner in the process is

cheaper.

So, we spend some of that 80% of our time writing tests instead

of all of it debugging.

We let our machine run those tests constantly for us.

We find mistakes sooner. Mistakes cost less. We sleep better. We enjoy life.

There is another benefit too. We write better code.

When you have tests for your code you have less fear of

change.

When you have tests, you can refactor your code. Your code

can continually improve in quality.

Also, testable code happens to have a whole lot in common with

well architected code

The title of this session mentions FlexUnit. I haven’t, so what is it?

Flex•Unit [fleks-yoo-nit ]–noun

1. a poorly named testing framework that supports unit and integration testing for Flex or ActionScript projects

2. a pluggable testing architecture which facilitates the use of multiple test runners and multiple test listeners

Unit Testing is taking the smallest piece of code,

isolated from any other factors and determining if it behaves

as you expect.

Integration Testing is assembling already tested units and ensuring the behavior and interaction between those

units are correct.

Functional testing is translating functional requirements of an application into scripts, which

can be executed to ensure requirements have been met.

Unit tests are for code that can be isolated. Therefore to be unit tested your code must have this

trait

To achieve this isolation, you can mock or you can stub

dependencies.

Here are some common techniques to ensure for code

isolation.

Separate construction from all other application/component

logic

function doSomeStuffHere():void {

//does stuff

var x:SomeClass = new SomeClass();

//does more stuff

}

function buildMeOne():SomeClass {

return new SomeClass();

}

function doSomeStuffHere():void {

//does stuff

var x:SomeClass = buildMeOne();

//does more stuff

}

Favor dependency injection over dependency lookup

function doIt():void {

//does stuff

var x:SomeClass = someSingleton.someObj;

//does more stuff

}

function doIt( someObj:SomeClass ):void {

//does stuff

//does more stuff

}

Code to an interface not to a implementation

function doIt( someObj:ISomeObj ):void {

//does stuff

//does more stuff

}

Don’t touch your grandchildren. Don’t play with another object’s

internals.

function doThing():void {

someObject.someProperty.someObj.method();

}

Avoid global state and access if you want to test it

function doThing():void {

addValue(singleton.getInstance().firstVal)

}

Separate Concerns because classes that can only be

described using the word AND are hard to test

Understanding FlexUnit

CoreCoreRequest Runner:Suite

Test Suite A

Test Case 1

TestTest TestTest

TestTest TestTest

Test Case 2

TestTest TestTest

TestTest TestTest

Test Case 3

TestTest TestTest

TestTest TestTest

Test Suite C

Test Case 7Test Case 7

Test Case 8Test Case 8

Test Suite B

Test Case 4

TestTest TestTest

TestTest TestTest

Test Case 5

TestTest TestTest

TestTest TestTest

Test Case 6

TestTest TestTest

TestTest TestTest

Test Suite D

Test Case 9Test Case 9

Test Case 10Test Case 10

Request.iRunner(Suite)

Request.iRunner(Suite)

Suite ASuite A Suite BSuite B

BlockRunner 1BlockRunner 1

BlockRunner 2BlockRunner 2

BlockRunner 3BlockRunner 3

Suite CSuite C

BlockRunner 7BlockRunner 7

BlockRunner 8BlockRunner 8

TestsTests

TestsTests

TestsTests

TestsTests

TestsTests

UIListenerUIListener

XMLListenerXMLListener

CIListenerCIListener

RunNotifierRunNotifier

Update a UIUpdate a UI

Send Data to ServerSend Data to Server

Send Data to Flash BuilderSend Data to Flash Builder

Some way to start itSomething to run it in

Someway to know if it passed or failed

Right now it can be started through, Flash Builder, Command

Line, Continuous Integration Systems, Ant, IntelliJ

Coming Soon to FDT and Flash Professional

Ways to run tests include FlexUnit .9, Fluint1, FlexUnit 4

(Theories, Params, others)

Ways to get data out include Flash Builder, XML, Flex UI

Coming Soon: The World

Questions?

Why Test with FlexUnit?

Michael LabriolaDigital Primates

@mlabriola