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

Like this? Share it with your network

Share

Why test with flex unit

on

  • 1,196 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,196
Views on SlideShare
1,189
Embed Views
7

Actions

Likes
2
Downloads
13
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 Presentation 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