Simple reminder to new coders and possibly old hands alike. unit tests.

jmgibson1981 · 04-03-2023, 12:05 PM

I spent the last 2 days staring at a library function I had written trying to figure out why it was seg-faulting. It worked fine in another program I was hacking at so it was annoying to say the least.

UNIT TESTS!

Had I not been dumb I would have made sure the file opened successfully. I had manually created the file and put the wrong file name in my global #define for that string. As such it failed to open every single time. Since I didn't have a prompt or error break on failure to open it would just segfault when my function to count the number of lines ran. I wasted a couple days getting pissed off for no reason.

The C course I started my journey with was on Udemy. The instructor wouldn't stop talking about unit tests at one point. Probably the most important lesson I've learned thus far now. Especially after wasting so much time for no reason.

Validate everything. While there is probably a point where it gets out of hand it will only help you to include a test for pretty much every variable and bit of data you compute in your stuff.

Code:

if (!fileptr)
{
  printf("unable to open file!\n");
  exit(1);
}

This small segment of code in this case, which I actually had created a library function with more data output about the error some time ago would have saved me 2 days of screwing around. And likely my blood pressure a bit as well.

NevemTeve · 04-03-2023, 01:22 PM

Or even:

Code:

FILE *efopen (const char *name, const char *mode)
{
    FILE *f;
    int ern;

    f = fopen (name, mode);

    if (f) return f;
    ern= errno;
    fprintf (stderr, "Error opening file \"%s\" mode \"%s\""
             " errno=%d: %s\n"
            , name, mode, ern, strerror (ern));
    exit (3004);
    return NULL;
}

sundialsvcs · 04-07-2023, 07:51 PM

Over many years, I single-handedly built a software product (in Delphi) which, I am very pleased to say, encountered almost no "runtime errors that made it out into the field." And one of the primary reasons why it did so was because I stuffed the programming which what might now be called assert()s ... and then never took them out. The programming was always built to be "suspicious," and if it detected anything wrong it would throw/raise a clearly-identified "exception." All of these tests were present in the deployed code.

Every now and then, one of these exceptions alerted me to what otherwise would have been "a nasty and hard-to-find bug." Except that it alerted me more-or-less exactly to where and what it was. It has been very many years since an actual customer has ever reported seeing any of these exceptions being thrown, and I never expect to encounter another one.

Likewise: the fact that these tests aren't going off reassures me that the underlying problems aren't happening.

But, I continue to write code in this way: "suspiciously." Because the code that is executing at this moment is in the very best position to recognize that "something has gone wrong." And, especially today, the "overhead" of performing these tests is zero.