Slides / Bullets
- Testing
- what is testing
      EXAMPLE: You'€™re writing a calculator, and you want to give it a
      gcd function.  So you do.  Then you run the program and feed it
      some values for which you know the result.  You do this until
      everything works.
    - running through your program
    - making sure the usual stuff works
    - making sure the new stuff works, too
- why test
    - humans make mistakes
    - bugs are expensive
    - bugs are demoralizing
    - you don'€™t want to deliver code with bugs
- ( file: gcd-1 )
- ( file: gcd-2 )
- Automated Testing
- what is automated testing
    - write a program
        - tell it what's normal
        - and what's new
        - let it do the work
- ( file: gcd-2.t )
- why to test automatically
      Humans tend to test only things they think have changed, but
      often little changes have weird consequences.  Computers are
      happy to test everything every time all the time always.
    - humans hate testing; computers don't
    - manual testing is expensive
    - manual testing is inconsistent
    - automated testing returns results instantly
- the automated testing philosophy
    - you are human
    - testing is an investment
    - test constantly
    - make testing part of your culture
- you are human
    - you're good, but not that good
    - your coworkers are human, too
    - humans are for thinking, not following scripts
    - machines never say, "It'll be fine, I'll commit it."
- testing is an investment
    - in quality
    - in laziness
    - in productivity
    - what's the cost of...
        - one little change breaking something obscure
        - delivering errors
        - getting called in on Saturday
- test constantly
      or make CVS test /when/ you commit
      
      Mozilla does this!
    - test before you commit
    - test as soon as you hit :w
    - write a bot to test for you
- testing in your culture
    - Don't write code that can't be tested
    - Any test that fails must be fixed immediately
    - Code reviews must include the  corresponding test files
    - Everyone on the team adds at least one new  test every day 
- ( file: gcd-2 )
- ( file: gcd-2.t )
- ( file: gcd-3 )
- ( file: gcd-3.t )
- what to test
    - new bugs
        - write a test for every bug when it's found
        - never release the same bug twice
    - new features
        - write a new test for every new feature
- what to test
    - Devel::Cover
    - coding standards
    - "write a test a day"
    - everything you can think of
- Testing First
- what is testing first
    - don't test the feature you just wrote
    - test the feature you're about to write
- what is testing first
    - how can I prove the feature works
        - write a test against the feature
        - it must fail
    - what's the simplest way to pass the test?
        - write the code
        - the test must now pass
- ( file: pants.t )
- ( file: pants-1.pm )
- ok, ok, not ok, not ok
- ( file: pants-2.pm )
- "All tests successful."
- why test first
      Well, that's not true.  They'll be written without preconceptions
      based on your code, anyway.
      
      as opposed to implement what you think you meant you wanted maybe
      sorta.
    - you'll have tests for everything
    - your tests will be written without preconceptions
    - your code will be written to implement a documented feature
    - in other words, test-first can take the place of design
        - yes, really
- why test first
    - by writing tests first, scope is well-defined
    - test-then-code will often take less time than code-then-test
- how far in advance?
    - one moment?
    - one feature?
    - one iteration?
    - the whole project?
- What to do now...
- 5 things to do Monday
      I admit it.  I stilll don'€™t have a smokebot.
    - Read Test::Tutorial
    - Start a test suite for one module
    - Start a smokebot
    - Start looking at t/*.t for modules you use
    - Spread the gospel
- 5 things to do next week
    - write tests for an entire module
    - add at least one new test every day
    - start keeping metrics
    - memorize Test::More, look into the other Test::* modules
    - read The Pragmatic Programmer
- 5 things for next month
    - post your first month of metrics
    - write data and application tests
    - modify your routine to require tests
    - start stealing ideas from other test frameworks
    - learn Test::Builder and write your own Test:: module
- the end (almost)
- Addendum
-
    - test.pl
    - Test::Simple
    - Test::More
    - Test::Harness
-
    - Test::Pod
    - Test::Signature
-
    - Test::LongString
    - Test::Differences
    - Test::DatabaseRow
-
    - Test::Builder
    - Test::Manifest