Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • It's no secret that I'm a fan of tests [] and testing []. Without tests, the big refactor and also the additiona RDBO layer would not be sane, workable, or stable. I drank the kool-aide long ago.

    For better or worse, I'm the group lead for a conversion to .NET at work along with a big fat site redesign. The first thing we are doing once we have the class files laid out are writing tests. They've all heard my speech and seen the demos about testing, coverage, proactively ensuring things "work today just like they did yesterday in so much as we've described in tests".

    There's no doubt that TDD/Unit testing is overwhelming at first glance. We've decided to take the incremental approach to tests.

    Round 1: Just test the method/property signatures. If you expect X, but get Y and are supposed to throw and error/exception, test that. If you call method Foo and should throw an error if Bar is not set, test that. That's easy to follow without much confusion.

    Round 2: Test code coverage only to see which methods/properties you havn't tested at all in the previous step. Don't obsess about the % number, just look for methods you haven't called.

    Round 3: Test positive functionality. If you call Y and should get X back, write a test for it.

    Round 4: When you fix a bug, write a test.

    Round 5: When people are finally comfortable with it all, game on. Try to fill in the test coverage gaps.

    It seems to be going well so far. I guess time will tell.
    • And Round 1-2 are at a point in the project where we're not writing the bulk of the code, just shelling out the structure. Rounds 3-5 are when we start actually making the classes work later. I also blame Petdance for the Test Your Environment mantra. I've also started exposing people to writing test when things god wrong, outside of code problems. Something stops working on a server? Write a test to make sure it's working correctly [when it does]. Spending time inspecting a database to pinpoint some data