Why test with flex unit

Why Test with FlexUnit? Michael Labriola Digital Primates @mlabriola

Who are you? Michael Labriola Senior Consultant at Digital Primates FlexUnit 4 Architect/Lead Developer Fan 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 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

Core Request.iRunner (Suite) Suite A Suite B BlockRunner 1 BlockRunner 2 BlockRunner 3 Suite C BlockRunner 7 BlockRunner 8 Tests Tests Tests Tests Tests UIListener XMLListener CIListener RunNotifier Update a UI Send Data to Server Send Data to Flash Builder Request Runner:Suite Test Suite A Test Case 1 Test Test Test Test Test Case 2 Test Test Test Test Test Case 3 Test Test Test Test Test Suite C Test Case 7 Test Case 8 Test Suite B Test Case 4 Test Test Test Test Test Case 5 Test Test Test Test Test Case 6 Test Test Test Test Test Suite D Test Case 9 Test Case 10

Some way to start it Something 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

Why test with flex unit

More Related Content

What's hot

Viewers also liked

Similar to Why test with flex unit

More from michael.labriola

Recently uploaded

Why test with flex unit

Editor's Notes