Your SlideShare is downloading. ×
Why test with flex unit
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Why test with flex unit

763

Published on

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

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
763
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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
  • Transcript

    • 1. Why Test with FlexUnit? Michael Labriola Digital Primates @mlabriola
    • 2. Who are you?
      • Michael Labriola
      • Senior Consultant at Digital Primates
      • FlexUnit 4 Architect/Lead Developer
      • Fan of Working Code
    • 3.
      • Are you a genius developer who writes perfect code without mistakes ?
    • 4.
      • 80% of your time as a developer is spent identifying and correcting defects .
    • 5.
      • Software mistakes cost the US Economy about 80 billion dollars a year .
    • 6.
      • Half of that is absorbed by consumers .
    • 7.
      • The other half is absorbed by the software developers
    • 8.
      • Errors cost more to fix the later in the process they are found
    • 9.
      • An error found after release can cost 100x more to fix than during early development
    • 10.
      • The point is that we need to do a better job of finding errors and we need to find them sooner .
    • 11.
      • The problem: Software developers , myself included, are hypocrites .
    • 12.
      • Developers will go out of there way to automate things .
    • 13.
      • We will spend time to automate code formatting and simple code generation
    • 14.
      • But when it comes to debugging , something we spend 80% of our time doing, we choose to do that manually
    • 15.
      • Why do you want to spend your time doing a repetitive task that a computer can do for you?
    • 16.
      • What do you think happens to your desire and ability to test when time gets short on a project?
    • 17.  
    • 18.  
    • 19.
      • How do we reverse this trend ?
      • How do we fix these issues ?
    • 20. In the beginner's mind there are many possibilities, in the expert's mind there are few -- Shunryu Suzuki
    • 21.
      • We need to change our approach. We need to do what we do best, automate .
    • 22.
      • Computers do repetitive tasks faster than we can. They also don’t tire of doing so.
    • 23.
      • That means if we automate our tests , we can run them continually .
    • 24.
      • Running tests continually means we find errors sooner . Finding errors sooner in the process is cheaper .
    • 25.
      • So, we spend some of that 80% of our time writing tests instead of all of it debugging.
    • 26.
      • We let our machine run those tests constantly for us.
    • 27.
      • We find mistakes sooner .
      • Mistakes cost less.
      • We sleep better.
      • We enjoy life .
    • 28.
      • There is another benefit too. We write better code .
    • 29.
      • When you have tests for your code you have less fear of change.
    • 30.
      • When you have tests , you can refactor your code. Your code can continually improve in quality.
    • 31.
      • Also, testable code happens to have a whole lot in common with well architected code
    • 32.
      • The title of this session mentions FlexUnit. I haven’t, so what is it?
    • 33.
      • 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
    • 34.
      • Unit Testing is taking the smallest piece of code, isolated from any other factors and determining if it behaves as you expect .
    • 35.
      • Integration Testing is assembling already tested units and ensuring the behavior and interaction between those units are correct.
    • 36.
      • Functional testing is translating functional requirements of an application into scripts , which can be executed to ensure requirements have been met.
    • 37.
      • Unit tests are for code that can be isolated . Therefore to be unit tested your code must have this trait
    • 38.
      • To achieve this isolation, you can mock or you can stub dependencies.
    • 39.
      • Here are some common techniques to ensure for code isolation.
    • 40.
      • Separate construction from all other application/component logic
    • 41.
      • function doSomeStuffHere():void {
      • //does stuff
      • var x:SomeClass = new SomeClass();
      • //does more stuff
      • }
    • 42.
      • function buildMeOne():SomeClass {
      • return new SomeClass();
      • }
      • function doSomeStuffHere():void {
      • //does stuff
      • var x:SomeClass = buildMeOne();
      • //does more stuff
      • }
    • 43.
      • Favor dependency injection over dependency lookup
    • 44.
      • function doIt():void {
      • //does stuff
      • var x:SomeClass = someSingleton.someObj;
      • //does more stuff
      • }
    • 45.
      • function doIt( someObj:SomeClass ):void {
      • //does stuff
      • //does more stuff
      • }
    • 46.
      • Code to an interface not to a implementation
    • 47.
      • function doIt( someObj:ISomeObj ):void {
      • //does stuff
      • //does more stuff
      • }
    • 48.
      • Don’t touch your grandchildren. Don’t play with another object’s internals .
    • 49.
      • function doThing():void {
      • someObject.someProperty.someObj.method();
      • }
    • 50.
      • Avoid global state and access if you want to test it
    • 51.
      • function doThing():void {
      • addValue(singleton.getInstance().firstVal)
      • }
    • 52.
      • Separate Concerns because classes that can only be described using the word AND are hard to test
    • 53.
      • Understanding FlexUnit
    • 54. 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
    • 55.
      • Some way to start it
      • Something to run it in
      • Someway to know if it passed or failed
    • 56.
      • Right now it can be started through, Flash Builder, Command Line, Continuous Integration Systems, Ant, IntelliJ
    • 57.
      • Coming Soon to FDT and Flash Professional
    • 58.  
    • 59.
      • Ways to run tests include FlexUnit .9, Fluint1, FlexUnit 4 (Theories, Params, others)
    • 60.
      • Ways to get data out include Flash Builder, XML, Flex UI
    • 61.
      • Coming Soon: The World
    • 62.  
    • 63.
      • Questions?
    • 64. Why Test with FlexUnit? Michael Labriola Digital Primates @mlabriola

    ×