Fallen into the pit of overconfidence
If someone had asked me yesterday whether I’m a professional, mature, seasoned developer. I would certainly replied “Indeed, I am!”. Well, fortunately, no one did, or else I can’t imagine meeting him/her again today after the pathetic thing below.
You see, I was working on a defect/bug yesterday, it was a pretty simple bug that I was happily to fix as it looks like a less than an hour job, so I did the fix below, got the test evidences and marked that defect as fixed, ready for promotion to the test environment.
private Boolean _someFlag;
private String _someOption;
private void Execute()
{
//... some codes here
// the following block of codes is the fix to resolve the defect/bug
if (_someOption.Contains("something"))
{
_someFlag = true;
}
else
{
_someFlag = false;
}
//... some codes here
}
To my horror this morning, there’s a new defect being raised, complaining that there’s an error pop-up whenever the user tried to click on the execute button.
And quickly I realized that the error was coming from the modified code above. And to make things worst, the code above is in the base class of let say 10 UI forms and 3 of them are now not working/usable at all due to this new bug.
Now fixing this new bug is another simple task to do, but the thing that stayed on my mind till now is that when I wrote that fix yesterday, it actually came to my mind that I should be putting some unit tests on them, this new bug will definitely get captured if I were to write the unit tests (basic positive, negative, null tests). But nah, my overconfidence took over that this is a simple fix, nothing’s going to ever happen with this fix, everything will be running happily tomorrow, I should check this in ASAP and hurrah! one defect down.
So what are the consequences with that?
- Testing activities were blocked on for 3 of 10 UIs, where actually without the code fix, all were actually working fine, it’s just a minor dodgy state that was incorrect
- One more day was wasted to get the new fix promoted so the testing can be continued
- For having end users/testers to actually see this error message, it’s embarrassing the development team
- And in the end, this kind of error is truly embarrassing for a .Net programmer, with these years of experiences for sure :|
(hope you don’t mind, Uncle Bob, I’ll make sure that I write the book review when I’m done reading your book :))
As you mature in your profession, your error rate should rapidly decrease towards the asymptote of zero. It won’t ever get to zero, but it is your responsibility to get as close as possible to it.
Hit the nail on the head of what I was expected to do. So moral of the story, be humble, don’t ignore your inner voice, and believe in unit testing/TDD.
PS: Tony, if you actually read this, just know that today in my head, i kept imagining you’re telling me “See, I told you, Bembeng” :p
Hah, yes indeed, it is always the simple things that go wrong.
You didn’t actually say, but I’m guessing the problem here is that _someOption is null, so the Contains won’t work.
The next thing to be wary of is overconfidence in your tests:
Red-Green-Refactor should be your mantra at all times – but if you are writing a very simple test, you can skip the Red and just write a passing test surely?
No! It is important that your test fails and that you see you are testing the correct piece of code. Not too long ago, I came across a test, co-incidentally using a Contains method on a collection.
The developer had written an extension Contains method, wrote a test using Contains, and it passed. All was well……except that his production code didn’t work.
Why? Well, he happened to pick a collection class that already had a perfectly good Contains method for the type of object he chose to test, lets say List, so his test actually tested the build in Contains and not his (buggy) implementation – doh!
Had he tried to make the test fail first, he would have seen the problem straight away because the test would have PASSED due to using the perfectly good base class implementation.
Incidentally, in this case, as an extension method, another way he could have caught the problem is to test ExtentionClass.Contains(myCollection, 123) rather than myCollection.Contains(123). Not only would this have forced the use of the extension method, it also makes it clear that you are testing an extension method and not just calling a base Contains as myCollection.Contains(123) suggests.
So the moral is, don’t be overconfident in your coding and don’t be overconfident in your tests either!
Hello m8, it’s always good to see your TDD wise words :)
Sorry for the late response on this, it’s just been another marathon for a release (you know the drills :p)
I totally agree with what you’re saying with the Red-Green-Refactor :)
I also just had an interesting 1 week piece of work, kind of peer programming, 1 guy does the back end/services, 1 guy does the GUI side (my part).
Totally new one UI (view) with few view models, so i took the chance to write the tests diligently enough (IMHO).
Starting from the view models, services, etc for several days then after I really think that all are in place and green then I did the view.
Oh boy, it’s really felt good, not the usual way of starting with the GUI first, but start from the test first.
An interesting experience and I’m glad that I did that, the integration with the back end stuffs can be considered as quite smooth, had several glitches here but those were mainly due to the contract, but overall it works and everyone’s happy :)
What a good way to end the week with :)