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:
... 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
Adrian
Re:I'd feel sad...
jplindstrom on 2009-05-16T18:36:21
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).
Re:I'd feel sad...
Adrian on 2009-05-16T19:09:05
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...
Refactoring should be continual. That's when you start getting real benefit. So I would see the card as a good sign - but also a sign that things could get better.
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
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 related objects that they could then test with. (If a property of one object was another, that would show up as a nested data structure, and the related objects would be created with appropriately connecting IDs.) When they were done the tests, they tore down all of the objects.
And now for the fun part. Suppose you needed to add a field to the object. All you did was add the field, made the "auto-create from YAML" method supply an appropriate default, and added some more data and tests. All of your previous tests would Just Work.
I was quite impressed and suggested to the guy who wrote the system that he should write an article about it. But he never did, and this is all proprietary code. (Which was on a project that later got abandoned.)
