in reply to Re: Test output: Interpret or pass/fail
in thread Test output: Interpret or pass/fail

One thing I am fond of is I use a little script to do the nifty rsync hard link diff backup on the directory that I am updating in, every few changes I make I save n run the script which (in the background) hard links the dir structure and creates a snapshot of the whole directory. After I am done for the day I will run my tests on the latest directory, if it fails I run the test down the list of directories until i find a pass then diff the last two directories. It makes finding core bugs that slip in very easy. The method to do the incs is here I use a small perl script to generate a hires timestamped dirname each rotation and vim to auto run it on save. The cool thing about it is you get all of those snapshots without much disk space cause it relys on hardlinks. I know this has little to do with your question, except adhoc tests would make something like this impossible.

-Waswas
  • Comment on Re: Re: Test output: Interpret or pass/fail

Replies are listed 'Best First'.
Re^3: Test output: Interpret or pass/fail
by adrianh (Chancellor) on Aug 07, 2003 at 06:39 UTC

    You might want to consider running your tests even more often - maybe even every time you hit save.

    That way you get to see any test failure quickly, and it's very likely to be related to a change you have just made - so the bug is even easier to track down.

      I used to, this way gives me three advantages.

      1. I tend to work more efficantly when I can stay on track -- If I have an idea how to improve something and get side tracked on fixing a bug that just poped in the code then I take a while to get back into the flow once I fix it. If my bugs were usually severe and requiring a complete redesign this would be moot.

      2. If I do implement solution X, and in the middle of implementation I figure out that solution Y is better for whatever reason I have many stop points I can jump back to implement solution Y.

      3. I can audit my code almost change by change and show movment.

      -Waswas

        I write test first and am very careful not to wear more than one of my programming, refactoring or debugging hats at any one time - so for me test-on-save works very well.

        As for stop points, code auditing, etc. I find a full source control system like CVS or Subversion a better fit than directory snapshots myself... but whatever works :-)