Test the Flex Applications- Final 2

®

Copyright 2008 Adobe Systems Incorporated. All rights reserved.

Testing Your Flex Applications

Michael Labriola

11/18/2008

®


Why do we care about testing?

Software errors cost a whole lot of money A 2002 NIST study found that software errors cost the US economy .6% of

the US GDP yearly[1]

That sets the net loss today at about 79.8 billion dollars a year

Who pays that? Approximately half of that is absorbed by people who buy software

The other half is absorbed by people who create software

[1] The Economic Impacts of Inadequate Infrastructure for Software Testing - http://www.nist.gov/director/prog-ofc/report02-3.pdf

®


Why do we care about testing?

Software errors are the majority of development cost The same NIST study found that, on average, 80% of development costs are

spent on identifying and correcting defects

So, the majority of the development time is spent creating software that still causes almost 80 billion in issues

The cost of fixing these errors is correlated to when they are found[2]

An requirements error found after release can cost 10 – 100 times as much to fix as during the requirements gathering phase

An architecture error found after release can cost 25-100 times as much to fix this late in the process

[2] McConnell, Steve (2004). Code Complete, 2nd edition, Microsoft Press, 960. ISBN 0-7356-1967-0.

®


Testing Defined

Which leads us to my definition of testing: Software Testing is a multi-faceted process designed to reduce development

cost and duration for the developing organization while simultaneously ensuring higher quality and lower total cost of ownership for the end user.

®


The Normal Perception

®


The Adjusted Perception

®


Types of Testing We Will Discuss

Manual / Scripted Humans create test scripts. Humans execute those tests.

Low cost to begin testing. High cost over the life of a project.

Testing generally happens less often.

Automated Humans create test methods. Machines execute those tests.

Higher cost to develop. Much lower cost over the life of a project.

Testing can happen continually.

®


Ways of Automated Testing

Testing as part of Development As developers create code, they create tests

Test Driven Development

Tests are continually executed by developer to ensure new code does not break existing features

Automated build/test environments Code checked out and built automatically

Code tested with your tests continually and reports issued

Automated QA ensuring a last minute check in does not break a release

®


Types of Automated Testing

Unit Tests the smallest functional unit of code

Usually tests a single method or function

One test for every path through a method

Integration Tests a combination of units

Can be used to test UI Components

Allows developers to ensure bottom up designed code works together

®


Types of Automated Testing

Functional Unlike Unit and Integration, generally not created by developers

Allows creating scripts based on specification instead of code

QA operator records a script, by clicking throughout the application

The script can then be replayed to verify functionality

®


Tools for Automated Testing

Unit Flex Unit - The original Flex/ActionScript 3.0 unit testing framework

designed and implemented by Adobe and community members. Mimics JUnit functionality and provides a solid unit testing base. After a long period of dormancy, it has recently been made an open source project. http://opensource.adobe.com/wiki/display/flexunit/FlexUnit

Fluint – Open source testing framework based on the style of FlexUnit but rewritten for better asynchronous support and the ability to test UI components. Fluint supports both unit and integration testing and introduces the concept of sequences to allow multi-step, asynchronous tests. http://fluint.google.com/

®



Unit ASUnit - Unit testing framework that supports Flash Player 6, 7, 8 and 9.

Good unit testing solution and should be a strong consideration if you are doing both Flex and Flash based projects. http://www.asunit.org/

FUnit – Metadata-driven testing framework for Flex 2 and 3. The project has a lot of potential but it currently in the alpha stage with no apparent support for asynchronous tests. http://blog.funit.org/

®



Integration Visual Flex Unit - an open source project to establish a framework for testing

a component’s visual appearance. Enhances FlexUnit with additional features to support "visual assertions“. In a nutshell, a visual assertion asserts that a component's appearance is identical to a stored baseline image file. http://code.google.com/p/visualflexunit/

Fluint – Uses sequences and events to check the runtime properties of various components and objects. http://fluint.google.com/

®



Functional HP Quick Test Pro – Longest running supporter of functional testing using

Flex. Works reasonably well, but lacks full asynchronous support http://tinyurl.com/2ama7g

IBM Rational – Very slick and functional tool, but lacks full property introspection capability.

http://tinyurl.com/2hgua8

Borland Silk 2008 – New offering from Borland providing both functional and performance testing

http://tinyurl.com/5dt7ln

http://tinyurl.com/2ama7g

http://tinyurl.com/2hgua8

http://tinyurl.com/5dt7ln

®



Functional - Community FunFX – Free functional testing suite for Flex based implemented with Ruby

http://funfx.rubyforge.org/

RIA Test – GUI test automation tool specifically for Flex. Great potential. Has property change watching support

http://riatest.com/

SeleniumFX – Flex portion of a larger testing project http://code.google.com/p/seleniumfx/

http://funfx.rubyforge.org/

http://riatest.com/

http://code.google.com/p/seleniumfx/

®



Somewhere in the middle FlexMonkey – Captures tests like a functional tool, but scripts those tests

within FlexUnit http://code.google.com/p/flexmonkey/

Log Based Testing RIA Logger – Uses the Flex logging framework to capture and compare log

messages. Serves as an alternative method of testing across many levels. http://renaun.com/blog/flex-components/rialogger/

http://code.google.com/p/flexmonkey/

http://renaun.com/blog/flex-components/rialogger/

®


An example application

®


Unit Testing

What unit tests can be written for these components?

There is no way you can answer.

Unit tests are generally written by the developer and are designed to test the smallest units.

Currently you have no idea what those are

Unit Test Demonstration and Examination

®


Integration Tests

What integration tests can be written for these components?

At this point you know that data is passed to the InfoPanel to display. So, you could verify that works.

You could also verify that next and previous broadcast appropriate events when clicked

You could also verify that the ZoomStrip appropriately changes its selectedIndex

Integration Test Demonstration and Examination

®


Functional Tests

What functional tests can be written for this application?

You can write a functional test for anything you should be able to do on the screen

Choose a new image, verify the fields

Click Next, verify the fieldsFunctional Test

Demonstration and Examination

®


Additional Requirements for Functional Testing

Delegates All standard Flex components work with the automation libraries to allow

property integration

Your own components need to create a delegate class to properly interact with the automation libraries

Walk through a delegate class for ZoomStrip

®


Code Coverage

Understanding Code Coverage Tests help in the entire development process, but if your tests are

incomplete, they can provide a false sense of security.

Code coverage examines your running tests to understand how much of your code they have exercised.

Demo of FlexCover with existing tests

®


CodeSlinger

http://blogs.digitalprimates.net/codeSlinger

Test the Flex Applications- Final 2

Documents

Transcript of Test the Flex Applications- Final 2