• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Why test with flex unit
 

Why test with flex unit

on

  • 1,094 views

Examining a few reasons why we are only punishing ourselves by not testing out code

Examining a few reasons why we are only punishing ourselves by not testing out code

Statistics

Views

Total Views
1,094
Views on SlideShare
1,087
Embed Views
7

Actions

Likes
2
Downloads
12
Comments
0

2 Embeds 7

http://www.slideshare.net 6
http://bb1trn.ic.uva.nl 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • These are influence diagrams from Test-Driven Development by Kent Beck.
  • These are influence diagrams from Test-Driven Development by Kent Beck.
  • Calligraphy Copyright © by Shunryu Suzuki. Quote by Shunryu Suzuki

Why test with flex unit Why test with flex unit Presentation Transcript

  • 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
    • Understanding FlexUnit
  • 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
    • Coming Soon: The World
  •  
    • Questions?
  • Why Test with FlexUnit? Michael Labriola Digital Primates @mlabriola