Your SlideShare is downloading. ×
0
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
Why test with flex unit
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

772

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
772
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

    ×