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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday May 15, 2009
04:16 AM

Refactoring Tests

[ #38979 ]

Today when I walked past another development team's Scrum board, I happened to notice that they had a card for "refactor tests". This made me happy. Too many developers out there are keen on refactoring code, but not on paying attention to their tests. This was part of my motivation for writing Test::Kit and Test::Most. You don't want to have a bunch of boilerplate at the top of all of your test modules, do you? No, you don't. Keep 'em simple, stupid!

Paying attention to code quality in test programs is at least as important as paying attention to code quality in the rest of your software, though in my experience, test quality usually gets short-changed. The main difference is that test programs often have data while regular ones don't. That makes managing them a bit more tricky. I've always been terribly ambivalent about the best way to manage this data. I should really look into this more.

The core problem with managing this data:

  • Either the test data or the data's structure is duplicated all over the place, causing massive pain if the structure changes and you must change all of your test data.
  • You don't want to duplicate your test data, so you group it in one place. But if it changes, you often have to change all of your test programs which use it (and developers come to rely on this identical data -- a bad habit leading to tunnel vision).
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.
  • ... that they feel the need to stick it up as a separate card rather than doing continual refactoring. I'd want to work with them on that :-)


    • What if you suddenly wake up an realize you have a large volume of duplicated test code (which may be the case, I have no idea)? Wouldn't you want to schedule time to make a serious difference?

      I think the presence of a card is a very un-sad thing for various reasons (they identified the problem, took action, got on scheduled time for it).

      • Yes. You're right. I was obviously feeling especially grumpy when I wrote that. The presence of the card is certainly a good sign that folk are paying attention to the code and know improvements need to be made. Yay :-)

        That said - I've seen too many folk who get into this nasty cycle of hack-code-until-mud... oh bugger.... better write some refactoring cards.... spend time persuading product owner than they really, _really_ need to do the refactoring cards.... refactor.... hack-code-until-mud... repeat...


  • It took my a long time to get it in my head that I should be writing my tests just like I wrie the code I'm testing: Modular and Reusable.

    It really hit home with me when I was writing tests for classes I knew other people would inherit or subclass. In that case, why not make it easier for the new distant coder to also reuse as much of your test suite as possible to also test their new code.

    That's sort of easy with Test::Class. Sometimes, it takes a little more effort in things like NUnit in .NET, where you'

  • In a former job I saw a system where every object was given a method to instantiate itself from a YAML data file. And by "instantiate itself" I include "Go and insert itself in the test database you are using." (You want your stored procedures and views properly tested, right?) And (this is important important), every field not specified in the YAML was automatically given a sensible default.

    Then in the test files they set up a nested YAML data structure that was automatically turned into a slew of relat