This talk is a combination of a few slides, much audience participation, conceptual demonstrations, and live code demonstrations. These elements are interwoven throughout the talk to engage the audience such that they can more easily digest the information being disseminated.

• Pre-show
  
  • Pre-talk warm up video
  • Looping slides of misleading questions to show how without the big picture you can easily jump to the wrong conclusion.
    
    • Q: What am I? Height = 5.9, Clothes = pink dress, bitch = true, body type = petite
    • A: picture of Tinkerbell, Paris Hilton’s Dog

• Testing: Ideology vs. Implementation

  • Audience survey

  • Are regression test important? ___ %

    • Do you run your code at least once before releasing? ___ %
    • Is your code well-covered by tests? ___ %
  • Group discussion:
  • Why is there such disparity between the 1st and 3rd question…?
  • Goal of talk:
    
    • Adding one line of code will give you automated regression tests
    • “You’re running your code anyway, so let’s ensure that that effort continues to protect your code.”
  • The cost of testing:
    
    • Testing simple results
    • Run code
      
      • We execute a piece of code and output the resulting integer to the console
    • Test code
      
      • We execute the piece of code and verify the resulting integer is correct
    • Summary
      
      • The same amount of work is done in both cases but the testing ensures protection for the future whereas running it only reports for the present
    • Testing complex results
    • Run code
      
      • We execute a piece of code and output the resulting paragraph to the console
    • Test code
      
      • We execute the piece of code but when we try to verify, it becomes cumbersome to retype the paragraph into the assert…
    • Approval Theater
    • This interactive demonstration (where we throw balls back and forth to the audience) creates the skeleton for how ApprovalTests work, to which the rest of the information in the talk is attached
    • Approval Test code
      
      • We execute the piece of code and approve the result, ensuring protection for the future
    • Summary
      
      • Doing ApprovalTests on complicated results is as easy as doing asserts on primitive values

• ApprovalTests (aka “Approvals”)

  • Here we delve into some high-value scenarios for ApprovalTests
  • Testing complexity
    
    • Lists
    • Testing every attribute of a list is a nightmare… Testing one attribute is insufficient… Where is the balance? Is there a better solution?
    • Live code example
    • GUIs
    • GUIs make lists look simple. Typically testers try to isolate the GUI and test the rest. Is there a better solution?
    • We will show how GUIs can be the easiest piece to test
    • Live code example
  • ApprovalTest API
    
    • Demonstrate the API’s extensibility
  • Visualization
    
    • “It is much easier to see something and know you want it then it is to explain what it is that you wanted in the first place…”
    • Bug detection
    • Traditionally once a bug is discovered, the developer needs to examine the code to figure out where the bug first appeared (slow tedious process)
    • ApprovalTesting invites you to rollback the visual results (not the code) to see where the bug first appeared and reports which developer made the change and when they did it
    • Readability
    • See the forest for the trees
    • Maintenance
    • Changes are now a click of a button after a view with powerful diff tools
  • Legacy code
    
    • We bring out a stopwatch to time the how long it takes to fully lock down a piece of working legacy code so you can refactor it safely
    • …Usually around 45 seconds
• Summary
  
  • Review of reasons why audience said their code was not well-covered by automated testing & validity of those obstacles in light of ApprovalTests
  • Recap goal (one line of code) & accomplishment of having achieved it