assertYourself()
Breaking All of the Theories and Assumptions of
               Unit Testing in Flex




         Michael ...
Who are you?
Michael Labriola
Senior Consultant at Digital Primates


Jeff Tapper
Senior Consultant at Digital Primates

 ...
What is this session about?

Automated Testing.

However, because we expect a mix of people at
  different levels of commi...
Topics I
Why Test Code – If you don’t know why this
 matters, you aren’t really going to care about
 the rest

Writing Tes...
Topics II
Writing Unit Tests – How do you go about writing
 and executing unit tests

Introducing Theories and DataPoints ...
The sad facts
Software Errors cost a lot of money and time
• A 2002 NIST study found that software errors cost
  the US ec...
More sad facts
Software errors are also the majority of development
  cost
• The same study found that, on average, 80% of...
The important part
The cost of fixing these errors is correlated to when
  they are found[2]
• A requirements error found ...
Why Test Automatically?
It allows us to test much more often than we could do so
   manually

• There are only so many hou...
Why Test Automatically?
It is cheaper than hiring teams of QA folks (or spending
    your time) to execute manual tests co...
Why Test Automatically?
It reduces the time to find and quash bugs

• Automated tests can run continuously
   – When you c...
Why Test Automatically?
It allows you to change and rewrite code without fear of
   breaking something else

• How do you ...
Why Test Automatically?
It increases the quality of the software you write

• If you write tests for your code, you tend t...
Last but not..
We appear to be more effective developers

When you deliver solid code that works the first time you
  are ...
Types of Testing
Unit
• Taking the smallest piece of code, isolated from any
  other factors and determining if it behaves...
More Testing
Functional
• Translating functional requirements of an application
  into test cases, which can be run to ens...
Coding for Testing
This is most of the battle. If you write code that follows these
  general architectural principals, te...
Coding for Testing
Separate construction and application logic
protected function doSomeStuffWithSomeClass():void {
  //do...
Coding for Testing
Use interfaces!

protected function positionThing(
  component:UIComponent ):void {
}

protected functi...
Coding for Testing
Don’t reach through another object for its
  properties

protected function doThing():void {
  someObje...
Coding for Testing
Avoid global state in things you wish to test

protected function doThing():void {
  addValue( mySingle...
Coding for Testing
New objects made through composition are easier
  than those created through inheritance

Composed obje...
Coding for Testing
Separate concerns

Classes which need the word *and* to explain
  them are hard to test

public functio...
Writing Unit Tests
What methods/classes should you write unit tests
 for?
• Anything that could possibly break
• Any metho...
Fakes, Stubs and Mocks
A unit test needs to test an isolated unit. Fakes,
  stubs and mocks are techniques for isolating
 ...
Fakes, Stubs and Mocks
Fakes and stubs are generally dumb objects which
  may respond or fulfill the requirement but do
  ...
Theories and DataPoints
What happens when we might need to write a
 test over a potentially infinite dataset of
 possibili...
Integration Tests
You have diligently tested all of the units you
  could; now how do you test them together?

Integration...
Integration Tests
In the simplest case, things look just like unit
  tests, call some methods, do assertions.

In more com...
Q&A
Seriously? You must have some questions by now?
Play and Vote
Take a look at the latest beta bits:

http://opensource.adobe.com/wiki/display/flexunit/FlexUnit


If you th...
Resources
Flex Unit 4!
http://opensource.adobe.com/wiki/display/flexunit/FlexUnit


Labriola’s Blog
http://blogs.digitalpr...
Upcoming SlideShare
Loading in...5
×

assertYourself - Breaking the Theories and Assumptions of Unit Testing in Flex

2,040

Published on

360|Flex Presentation on Unit Testing

Published in: Technology, Education
1 Comment
6 Likes
Statistics
Notes
  • the video i like thanks
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
2,040
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
72
Comments
1
Likes
6
Embeds 0
No embeds

No notes for slide
  • [1] The Economic Impacts of Inadequate Infrastructure for Software Testing - http://www.nist.gov/director/prog-ofc/report02-3.pdf
  • [2] McConnell, Steve (2004). Code Complete, 2nd edition, Microsoft Press, 960. ISBN 0-7356-1967-0.
  • assertYourself - Breaking the Theories and Assumptions of Unit Testing in Flex

    1. 1. assertYourself() Breaking All of the Theories and Assumptions of Unit Testing in Flex Michael Labriola Jeff Tapper Digital Primates
    2. 2. Who are you? Michael Labriola Senior Consultant at Digital Primates Jeff Tapper Senior Consultant at Digital Primates Flex Geeks - Team Mentors Fans of Working Code
    3. 3. What is this session about? Automated Testing. However, because we expect a mix of people at different levels of commitment to the idea of testing we need to cover a few major areas
    4. 4. Topics I Why Test Code – If you don’t know why this matters, you aren’t really going to care about the rest Writing Testable Code – 99% of writing good tests is good architecture.
    5. 5. Topics II Writing Unit Tests – How do you go about writing and executing unit tests Introducing Theories and DataPoints – verifying functionality over a larger set of values Writing Integration Tests – Integrate your units and let the real fun begin
    6. 6. The sad facts Software Errors cost a lot of money and time • A 2002 NIST study found that software errors cost the US economy .6% of the US GDP yearly[1] • That sets the net loss today at about 79.8 billion dollars a year Who pays that? • Half of that is absorbed by people who buy software • The other half is absorbed by people who create software
    7. 7. More sad facts Software errors are also the majority of development cost • The same study found that, on average, 80% of development costs are spent on identifying and correcting defects • So, the majority of the development time is spent creating software that still causes almost 80 billion in issues
    8. 8. The important part The cost of fixing these errors is correlated to when they are found[2] • A requirements error found after release can cost 10 – 100 times as much to fix as during the requirements gathering phase • An architecture error found after release can cost 25- 100 times as much to fix this late in the process • The point.. Finding issues early == good. Finding issues late == bad.
    9. 9. Why Test Automatically? It allows us to test much more often than we could do so manually • There are only so many hours in the day. • Code that hasn’t been exercised in a while is always suspect • When you’re tired, do you test as effectively? Computers tend not to get tired.
    10. 10. Why Test Automatically? It is cheaper than hiring teams of QA folks (or spending your time) to execute manual tests continually • Automated tests cost money to write and money to maintain, however, once a test is written, you can run it forever for a near zero cost. • Manual testing which costs little in the beginning, but re-occurs every time you wish to test
    11. 11. Why Test Automatically? It reduces the time to find and quash bugs • Automated tests can run continuously – When you create a new bug, it is likely to be caught in a very short period of time. – When you have context, you fix issues more quickly – The longer you wait to resolve a bug, the more likely it is that more code will need to be touched
    12. 12. Why Test Automatically? It allows you to change and rewrite code without fear of breaking something else • How do you know that a seemingly innocuous change in a piece of code today doesn’t have repercussions in some rarely run portion of the project? • With sufficient tests you can change code and sleep better
    13. 13. Why Test Automatically? It increases the quality of the software you write • If you write tests for your code, you tend to ensure the architecture can support testing… generally that also means you architected it at least mostly okay • Code with a lot of automated tests will have been tested thousands of times in the course of development • Bugs will still exist, but they are less likely to be fundamental and immediately noticeable
    14. 14. Last but not.. We appear to be more effective developers When you deliver solid code that works the first time you are perceived as effective
    15. 15. Types of Testing Unit • Taking the smallest piece of code, isolated from any other factors and determining if it behaves as you expect. Integration • Assembling already tested units and ensuring the behavior and interaction between those units are correct.
    16. 16. More Testing Functional • Translating functional requirements of an application into test cases, which can be run to ensure requirements have been met. A million or so more varieties • Performance, acceptance, etc., etc.
    17. 17. Coding for Testing This is most of the battle. If you write code that follows these general architectural principals, testing it is viable and less stressful. If you don’t, well, good luck
    18. 18. Coding for Testing Separate construction and application logic protected function doSomeStuffWithSomeClass():void { //does stuff var x:SomeClass = new SomeClass(); //does more stuff } protected function doSomeStuffWithSomeClass( someClass:SomeClass ):void { //does stuff //does more stuff }
    19. 19. Coding for Testing Use interfaces! protected function positionThing( component:UIComponent ):void { } protected function positionThing( component:IUIComponent ):void { }
    20. 20. Coding for Testing Don’t reach through another object for its properties protected function doThing():void { someObject.someProperty.someObj.method(); }
    21. 21. Coding for Testing Avoid global state in things you wish to test protected function doThing():void { addValue( mySingleton.getInstance().firstVal ); }
    22. 22. Coding for Testing New objects made through composition are easier than those created through inheritance Composed objects can be substituted with different composition at runtime. You can’t change your parents.
    23. 23. Coding for Testing Separate concerns Classes which need the word *and* to explain them are hard to test public function createObjectsAndPositionThem():void;
    24. 24. Writing Unit Tests What methods/classes should you write unit tests for? • Anything that could possibly break • Any method that can’t be verified by simple inspection When writing tests you are either checking a return value or looking for a side-effects created by a method. – If a method doesn’t do either, what in the world does it do?
    25. 25. Fakes, Stubs and Mocks A unit test needs to test an isolated unit. Fakes, stubs and mocks are techniques for isolating the unit under test. For our purposes Fake object, stub and mock objects are objects that are instantiated instead of real implementations when an object under test expects to interact with other objects.
    26. 26. Fakes, Stubs and Mocks Fakes and stubs are generally dumb objects which may respond or fulfill the requirement but do little else. Mock objects allow you to set expectations of how they will be ‘touched’ during the test and then make assertions based on those expectations
    27. 27. Theories and DataPoints What happens when we might need to write a test over a potentially infinite dataset of possibilities? What if you need to test objects in multiple states with different data points?
    28. 28. Integration Tests You have diligently tested all of the units you could; now how do you test them together? Integration tests are less likely to use mocks, and more likely to test all real units involved
    29. 29. Integration Tests In the simplest case, things look just like unit tests, call some methods, do assertions. In more complicated situations, you may need to deal with asynchronous aspects In even more complicated situations, you may need to do a fair amount of setup to get to the point needing a test
    30. 30. Q&A Seriously? You must have some questions by now?
    31. 31. Play and Vote Take a look at the latest beta bits: http://opensource.adobe.com/wiki/display/flexunit/FlexUnit If you think the new features are important to your workflow, let Adobe know: https://bugs.adobe.com/jira/browse/FB-18873
    32. 32. Resources Flex Unit 4! http://opensource.adobe.com/wiki/display/flexunit/FlexUnit Labriola’s Blog http://blogs.digitalprimates.net/codeSlinger/ Tapper’s Blog http://blogs.digitalprimates.net/jefftapper/ Follow us on twitter mlabriola and jefftapper
    1. A particular slide catching your eye?

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

    ×