mardi 6 septembre 2016

Should Testing Code be Isolated from Production Code, even when it doubles or triples costs?

Say I have a class DoStuff:

 public DooHickey DoStuff(int thingId) {
        var thing = GetThing(thingId);
        SendNotification(thing);
        DoComplicatedStuff(thing);
 }

Today, I encountered a bug with DoComplicatedStuff for a particular kind of Thing. So I rewrote DoStuff as follows:

 public DooHickey DoStuff(int thingId) {
        var thing = GetThing(thingId);
        if (thing.TestingMode != TestingMode.SkipNotification)
             SendNotification(thing);
        DoComplicatedStuff(thing);
 }

There are a couple different scenarios here and this particular section of code is mission-critical, so I added a TestingMode property to the model so I could quickly go about testing particular cases.

I sacrificed code quality here for speedy resolution, but what I'm wondering is - how bad is this, and what's the next step in maturing the approach? I don't want to go and create tons of interfaces and subclasses and increase complexity tenfold to be "right", but I don't want to be "awful" either. Right now the code is readable, the intent is clear, and the problem has been solved and we can easily go and retest it by creating a new object.

Aucun commentaire:

Enregistrer un commentaire