Why Test with FlexUnit? Michael Labriola Digital Primates @mlabriola
Who are you? <ul><li>Michael Labriola </li></ul><ul><li>Senior Consultant at Digital Primates </li></ul><ul><li>FlexUnit 4...
<ul><li>Are you a genius  developer  who writes perfect code  without   mistakes ?  </li></ul>
<ul><li>80%  of  your time  as a developer is spent  identifying  and  correcting defects . </li></ul>
<ul><li>Software  mistakes   cost  the US Economy about  80 billion  dollars  a   year .  </li></ul>
<ul><li>Half of that is  absorbed   by   consumers .  </li></ul>
<ul><li>The other half is  absorbed   by  the  software developers </li></ul>
<ul><li>Errors   cost   more  to fix the  later  in the process they are found </li></ul>
<ul><li>An  error  found  after release  can  cost   100x more  to fix than during early development </li></ul>
<ul><li>The point is that we need to do a better job of  finding errors  and we need to find them  sooner . </li></ul>
<ul><li>The problem: Software  developers , myself included,  are   hypocrites . </li></ul>
<ul><li>Developers  will go out of there way to  automate things .  </li></ul>
<ul><li>We will spend time to  automate  code  formatting  and simple code  generation </li></ul>
<ul><li>But when it comes to  debugging , something we spend 80% of our time doing, we choose to do that  manually </li></ul>
<ul><li>Why  do you want to  spend  your  time  doing a  repetitive task  that a computer can do for you? </li></ul>
<ul><li>What  do you think  happens  to your desire and ability to test  when   time  gets  short  on a project? </li></ul>
 
 
<ul><li>How do we  reverse  this  trend ?  </li></ul><ul><li>How do we  fix  these  issues ? </li></ul>
In the beginner's mind there are many possibilities, in the expert's mind there are few -- Shunryu Suzuki
<ul><li>We need   to  change our approach. We need to do what we do best,  automate . </li></ul>
<ul><li>Computers  do  repetitive  tasks  faster  than we can. They also  don’t tire  of doing so. </li></ul>
<ul><li>That means if we  automate  our  tests , we can  run  them  continually . </li></ul>
<ul><li>Running tests  continually means  we find errors  sooner . Finding errors  sooner  in the process  is   cheaper . ...
<ul><li>So, we  spend  some of that 80% of our  time writing tests  instead of all of it debugging. </li></ul>
<ul><li>We let our machine  run  those  tests   constantly  for us. </li></ul>
<ul><li>We  find mistakes sooner .  </li></ul><ul><li>Mistakes cost less.  </li></ul><ul><li>We sleep better.  </li></ul><...
<ul><li>There is another  benefit  too. We write  better code . </li></ul>
<ul><li>When you have  tests  for your code you have  less fear  of change.  </li></ul>
<ul><li>When you have  tests , you can  refactor  your code.  Your code can continually  improve  in quality. </li></ul>
<ul><li>Also,  testable code  happens to have a whole lot in common with  well   architected code </li></ul>
<ul><li>The title of this session mentions FlexUnit. I haven’t, so what is it? </li></ul>
<ul><li>Flex•Unit  [fleks-yoo-nit ] </li></ul><ul><li>– noun </li></ul><ul><ul><li>a poorly named testing framework that s...
<ul><li>Unit Testing  is taking the  smallest  piece of code,  isolated  from any other factors and determining if it  beh...
<ul><li>Integration Testing  is assembling already tested units and ensuring the behavior and  interaction between  those ...
<ul><li>Functional testing  is translating functional  requirements  of an application  into scripts , which can be execut...
<ul><li>Unit tests  are for code that can be  isolated . Therefore to be unit tested your  code  must have this trait </li...
<ul><li>To achieve this isolation, you can  mock or  you can  stub dependencies. </li></ul>
<ul><li>Here are some  common techniques  to ensure for code isolation. </li></ul>
<ul><li>Separate construction  from all other application/component logic </li></ul>
<ul><li>function doSomeStuffHere():void { </li></ul><ul><li>//does stuff </li></ul><ul><li>var x:SomeClass = new SomeClass...
<ul><li>function buildMeOne():SomeClass { </li></ul><ul><li>return new SomeClass(); </li></ul><ul><li>} </li></ul><ul><li>...
<ul><li>Favor dependency injection  over dependency lookup </li></ul>
<ul><li>function doIt():void { </li></ul><ul><li>//does stuff </li></ul><ul><li>var x:SomeClass = someSingleton.someObj; <...
<ul><li>function doIt( someObj:SomeClass ):void { </li></ul><ul><li>//does stuff </li></ul><ul><li>//does more stuff </li>...
<ul><li>Code to an  interface   not  to a  implementation </li></ul>
<ul><li>function doIt( someObj:ISomeObj ):void { </li></ul><ul><li>//does stuff </li></ul><ul><li>//does more stuff </li><...
<ul><li>Don’t touch  your grandchildren. Don’t play with another  object’s internals . </li></ul>
<ul><li>function doThing():void { </li></ul><ul><li>someObject.someProperty.someObj.method(); </li></ul><ul><li>} </li></ul>
<ul><li>Avoid global  state and access if you want to test it </li></ul>
<ul><li>function doThing():void { </li></ul><ul><li>addValue(singleton.getInstance().firstVal) </li></ul><ul><li>} </li></ul>
<ul><li>Separate Concerns  because classes that can only be described using the word AND are hard  to test </li></ul>
<ul><li>Understanding FlexUnit </li></ul>
Core Request.iRunner (Suite) Suite A Suite B BlockRunner 1 BlockRunner 2 BlockRunner 3 Suite C BlockRunner 7 BlockRunner 8...
<ul><li>Some way to start it </li></ul><ul><li>Something to run it in </li></ul><ul><li>Someway to know if it passed or fa...
<ul><li>Right now it can be started through, Flash Builder, Command Line, Continuous Integration Systems, Ant, IntelliJ </...
<ul><li>Coming Soon to FDT and Flash Professional  </li></ul>
 
<ul><li>Ways to run tests include FlexUnit .9, Fluint1, FlexUnit 4 (Theories, Params, others) </li></ul>
<ul><li>Ways to get data out include Flash Builder, XML, Flex UI </li></ul>
<ul><li>Coming Soon: The World </li></ul>
 
<ul><li>Questions? </li></ul>
Why Test with FlexUnit? Michael Labriola Digital Primates @mlabriola
Upcoming SlideShare
Loading in...5
×

Why test with flex unit

785

Published on

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
785
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
2
Embeds 0
No embeds

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
  • Why test with flex unit

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

      Clipping is a handy way to collect important slides you want to go back to later.

    ×