Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The problem with the test that expected an exact match only becomes a bug in the test when you change the output. So, you roll back your changes, refactor the failing test to accept more generic input, make sure it still passes without your changes and then redo your changes (consider doing a quick smoke test by deliberately breaking the thing it's supposed to test to make sure it fails correctly too).

    With TDD you are holding your tests to the same standard as your code; tests should be good enough for rig
  • Absolutely! (Score:2, Interesting)

    • While we admittedly do some strange things in tests (I override function definitions left and right), for the most part, good software practices apply to tests because tests are software.

    I couldn't agree more.

    Being an ardent advocate of TDD, I wouldn't think of writing a line of test software before I have the tests for that test software in place. Of course, the test-tests are also software and require that tests for them be written first and those tests require that tests, well you get the idea.

    • The nice part about TDD is that the tests test the code and the code tests the test. That is, if you write a test, make sure it fails, write the code, make sure it passes, you can avoid most of the worry.

      Writing a good test library is harder, though.