Docendo discimus


  • Calendar

    October 2008
    M T W T F S S
  • Archives

  • Recent Posts

  • Bling

How I learned to stop worrying…

Posted by brunorc on October 30, 2008

It wasn’t so obvious to me when I bought this book (original version), and even in the time of reading. At least all those nifty tests running during Perl modules installation had some meaning to me… Nonetheless, if smarter than me advised to write tests – I made them a part of my workshop.

Sooner the advantage of having testing suite ahead of writing code became obvious. Having some kind of “living specification” gave me a huge performance thrust, mostly because of the instant gratification. But what was even more important, I was able to track down every improvement, which unintentionally broke some other behavior, implemented before.

But lately I discovered another upside, which importancy is even more significant in the world of Open Source. Namely, it is the possibility to discover some bugs in the external code – modules, libraries, whatever. And not only one can discover it, but while reporting one can provide the failing test. Of course one can use this test not only for reporting, but also for trying his brand new patch before submitting it…

There is some witty saying (based on the famous Murphy’s Law), stating that “cool tools works only in others’ gardens”. So while for many people test are not cool, you can treat this lack of coolness as a proof that tests will work for you. And once you have discovered that tests are really cool, you don’t need such proofs anymore.

One Response to “How I learned to stop worrying…”

  1. Czajnik said

    Well, everything is fine as long as you have enough time for testing, and if you have technical possibilities to do it.

    I’m working on DVB set-top box firmware – here the software is closely coupled with hardware it runs on – if you want to do any white-box tests of e.g. video decoder, you’d need to simulate the whole hardware. Well, that could improve the quality by order of magnitude, but in the real world no-one can afford it.

    Sure, we do test higher-lever APIs using the test harness, and it is helpful, but still lots of problems remains – mostly timing-related, hardware-related etc., i.e. things that are sometimes extremely hard to reproduce in artificial test environment.

    Speaking of time pressure – that’s another story. It’s a common practice to trade quality for time. If we spend more time improving the quality, our competitor will win the contract, despite the quality of his product , just because he’s faster :) That’s a bit pathological, I know…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: