Wow, automated tests are saving my ass right now

[afuna]

When I first did renames, I didn't have the concept of a rename token object -- I had the shop item, and then I was doing a bunch of stuff directly in DW::Rename. At some point, I rethought, and encapsulated some of that logic into a new class DW::RenameToken, and I had to do a lot of tweaks to what I had already done to accommodate it.

I'm so *absolutely grateful* that szabgab did such a job towards making existing tests usable, because that put tests in mind when I first started doing the renames module, and I felt obliged to take the time to wrote a few simple tests.

Now the tests are failing, and in all the ways that point out to me where my old assumptions no longer bear weight under the new/tweaked code. They have paid for themselves many times over.

Now how do we convince others to write more of these things? :-)

Comments

[azurelunatic]

Congratulations on your latest round of safe failure!

[afuna]

Safe failure!

Hmmm, I like the sound of that. More room to fail without hurting anyone/anything!

[pauamma]

Now how do we convince others to write more of these things?

Good question. Offhand, what fraction of the bugs in committed and pushed code (which are for obvious reasons the ones we most want to avoid) do you think would have been spotted by appropriate tests?

[afuna]

Hmm, I don't know, honestly. I think that as we move to tt, and better separation of view versus the more testable controllers (instead of mixing a lot of stuff into a bml page), the percentage of bugs preventable by tests would go up. Which doesn't quite answer your question, does it?

[pauamma]

Hmm, yes. Good point. (And no, it doesn't, but I suspect the answer is along the lines of "not a lot, and the effort involved in writing an automated test to check for these bugs and prevent a regression would be out of proportion with the gain.")

[afuna]

I think it's worth investing in an ongoing effort to write bugs for old code (because that's the code we'll be modifying), especially if it's like...stuff that we're going to restructure, while wanting to make sure that we don't break old expected behavior (if we do do that. I'm not sure if there's anything currently on the plate?).

But a better investment, and one that's less likely to fizzle out/burn out, is to try to code stuff for new modules, as you code them. I still need to sort my thoughts out for how to write something appropriate for dw_dev, but it's something I'd like to encourage!

[synecdochic]

Now how do we convince others to write more of these things? :-)

Write out a detailed explanation of what tests are, how to write them, and why we should write them, suitable for a four-year-old child, so that new programmers who are Very Slow, aka me, know what the hell to do? :)

[foxfirefey]

This! And also post to dw_dev, so that more developers can go oooo.

[pauamma]

Hmm. One thing you can do is keep a log of the errors you fixed when you were testing your patch (and the state of your patch that had the error). Then, sit down with someone and go over that log to try to extract tests from the bug descriptions. It's usually not something you can do alone until you gain some experience, and have insight into where your blind spots are so you can write tests to probe them. That said, it's definitely something that (IMO) is worth discussing, so a dw_dev entry like foxfirefey suggested is probably a good idea.

[miome.livejournal.com]

Reminds me of one of my favorite sayings, "if it's not tested, it's broken".

[afuna]

Oooh I like that!