* * * * *
                                        
                        Another attempt at a “unit test”
                                        
Or, “What is a ‘unit test,’ part III [1]” 

The reactions to my previous post were interesting—it wasn't a “unit test.”
At best, it might have been an “integration test” but because it involved
actual work (i.e. (that is) interaction with the outside world via nasty
nasty side effects, aka (also known as) I/O (Input/Output)) it immediately
disqualified it as a “unit test.” And to be honest, I was expecting that type
of reaction—it appears to me that most unit test proponents tend to avoid
such “entanglements” when writing their “battle tested” code (but I'm also
willing to admit that's the cynical side of me talking). There were also
comments about how 100% code coverage was “unrealistic.” 

Sigh.

One respondent [2] even quoted me out of context—“… that we as programmers
are not trusted to write code without tests …” and cut the rest of the
sentence: “… yet we're trusted to write a ton of code untested as long as
such code is testing code.” Which was my cynical take that the “unit tests”
(or the code that implements “unit tests” ) are, themselves, not subjected to
“unit tests.” Something I kept trying to impart to my former manager, “stop
taking the unit tests as gospel! I don't even trust them!” (mainly because
the business logic of the project was convoluted and marketing kept using
different terms from engineering, at least engineering in my department)

But when I left off, I said there was one final function [3] that should fit
as a “unit,” and thus, perfect for “unit testing.” Again, it's from my blog
engine [4] and the function in question deals with parsing a request, like
“2001/10/02.2-11/03.3” (which requests all blog posts starting from the
second post on October 2^nd to the third post of November 3^rd, 2001). or
“2001/11/04.2” (the second post from November 4^th, 2001).

The function tumbler_new() does no I/O (that is—no disk, network or console
I/O), touches no global variables, only works with the data given to it and
does some covoluted parsing of the input data—if this isn't a good candidate
for “unit tests” then I don't know what is.

The tests were straightforward—a bunch of failure cases:

-----[ C ]-----
  tap_assert(!tumbler_new(&tumbler,"foo/12/04.1",&first,&last),"non-numberic year");
  tap_assert(!tumbler_new(&tumbler,"1999/foo/04.1",&first,&last),"non-numeric month");
  tap_assert(!tumbler_new(&tumbler,"1999/12/foo.1",&first,&last),"non-numeric day");
  tap_assert(!tumbler_new(&tumbler,"1999/12/04.foo",&first,&last),"non-numeric part");
  tap_assert(!tumbler_new(&tumbler,"1998",&first,&last),"before the start year");
  tap_assert(!tumbler_new(&tumbler,"1999/11",&first,&last),"before the start month");
  tap_assert(!tumbler_new(&tumbler,"1999/12/03",&first,&last),"before the start day");
  tap_assert(!tumbler_new(&tumbler,"1999/12/04.0",&first,&last),"part number of 0");
  tap_assert(!tumbler_new(&tumbler,"2023",&first,&last),"after the end year");
  tap_assert(!tumbler_new(&tumbler,"2022/11",&first,&last),"after the end month");
  tap_assert(!tumbler_new(&tumbler,"2022/10/07",&first,&last),"after the end day");
  tap_assert(!tumbler_new(&tumbler,"2022/10/06.21",&first,&last),"after the end part");
  tap_assert(!tumbler_new(&tumbler,"1999/00/04.1",&first,&last),"month of 0");
  tap_assert(!tumbler_new(&tumbler,"1999/13/04.1",&first,&last),"month of 13");
  tap_assert(!tumbler_new(&tumbler,"1999/12/00.1",&first,&last),"day of 0");
  tap_assert(!tumbler_new(&tumbler,"1999/12/32.1",&first,&last),"day of 32");
  tap_assert(!tumbler_new(&tumbler,"1999/12/04.0",&first,&last),"part of 0");
  tap_assert(!tumbler_new(&tumbler,"1999/12/04.24",&first,&last),"part of 24");
  tap_assert(!tumbler_new(&tumbler,"2010/07/01-04/boom.jpg",&first,&last),"file with range");
  tap_assert(!tumbler_new(&tumbler,"2010/7/1-4/boom.jpg",&first,&last),"file with redirectable range");
-----[ END OF LINE ]-----

Plus a bunch of tests that should pass:

-----[ C ]-----
  test("first entry","1999/12/04.1",&(tumbler__s) {
    .start    = { .year = 1999 , .month = 12 , .day = 4 , .part = 1 },
    .stop     = { .year = 1999 , .month = 12 , .day = 4 , .part = 1 },
    .ustart   = UNIT_PART,
    .ustop    = UNIT_PART,
    .segments = 0,
    .file     = false,
    .redirect = false,
    .range    = false,
    .filename = ""
  });
  
  test("some mid entry","2010/07/04.15",&(tumbler__s) {
    .start    = { .year = 2010 , .month = 7 , .day = 4 , .part = 15 },
    .stop     = { .year = 2010 , .month = 7 , .day = 4 , .part = 15 },
    .ustart   = UNIT_PART,
    .ustop    = UNIT_PART,
    .segments = 0,
    .file     = false,
    .redirect = false,
    .range    = false,
    .filename = ""
  });
  
  test("last entry","2022/10/06.20",&(tumbler__s) {
    .start    = { .year = 2022 , .month = 10 , .day = 6 , .part = 20 },
    .stop     = { .year = 2022 , .month = 10 , .day = 6 , .part = 20 },
    .ustart   = UNIT_PART,
    .ustop    = UNIT_PART,
    .segments = 0,
    .file     = false,
    .redirect = false,
    .range    = false,
    .filename = ""
  });
  
  test("requesting a file","2010/07/04/boom.jpg",&(tumbler__s) {
    .start    = { .year = 2010 , .month = 7 , .day = 4 , .part =  1 },
    .stop     = { .year = 2010 , .month = 7 , .day = 4 , .part = 23 },
    .ustart   = UNIT_DAY,
    .ustop    = UNIT_DAY,
    .segments = 0,
    .file     = true,
    .redirect = false,
    .range    = false,
    .filename = "boom.jpg",
  });

  /* ... other tests ... */
-----[ END OF LINE ]-----

With this function checking the results:

-----[ C ]-----
static void test(char const *tag,char const *tum,tumbler__s const *result)
{
  tumbler__s  tumbler;
  
  assert(tag    != NULL);
  assert(tum    != NULL);
  assert(result != NULL);

  tap_plan(10,"%s: %s",tag,tum);
  tap_assert(tumbler_new(&tumbler,tum,&first,&last),"create");
  tap_assert(btm_cmp(&tumbler.start,&result->start) == 0,"start date");
  tap_assert(btm_cmp(&tumbler.stop,&result->stop) == 0,"stop date");
  tap_assert(tumbler.ustart == result->ustart,"segment of start");
  tap_assert(tumbler.ustop == result->ustop,"segment of stop");
  tap_assert(tumbler.segments == result->segments,"number of segments");
  tap_assert(tumbler.file == result->file,"file flag");
  tap_assert(tumbler.redirect == result->redirect,"redirect flag");
  tap_assert(tumbler.range == result->range,"range flag");
  tap_assert(strcmp(tumbler.filename,result->filename) == 0,"file name");
  tap_done();
}
-----[ END OF LINE ]-----

I ended up with a total of 328 tests and of the three attempts I made, this
one feels like the only one that was worth the effort—it's a moderately long
function [**Moderately** long? It's 450 lines long! —Editor] [But it does one
thing, and one thing well—it parses a request! —Sean] [450 lines! —Editor]
[I'd like to see you write it then! —Sean] [… Okay, I'll shut up now. —
Editor] that implements some tricky logic and deal with some weird edge
cases. If I ever go back to rework this code (and I've only revised this code
once in the 23 years it's been used, way back in 2015—it was a full rewrite
of the function) the tests could be useful (if I'm honest with myself, and
the API/structure doesn't change). [DELETED-And from looking over the test
cases, I can see that I could get rid if .segments from the structure, so
there's that.-DELETED](Seems I was wrong---the .segments field is needed for
tumbler_canonical())

Overall, I'm still not entirely sure about this “unit test” stuff, especially
since “unit” doesn't have a well defined meaning. In my opinion, I think it
works best for functions that do pure processing (no interaction with the
outside world) and that implement some complex logic, like parsing or
business logic. Back when I was at The Enterprise, had we but one function
(or entry point) that just implemented all the business logic from data
gathered from the request, it would have have made testing so much easier.
But “unit tests” for all functions? Or modules? Or whatever the XXXX a “unit”
is? No. Not for obvious code [5], or for for code that interacts with
external systems [6] (unless required because human lives are on the line).
I'm not saying no to tests entirely, but to the slavish adherence to testing
for its own sake. 

Or maybe, instead of having AI (Artificial Intelligence) write code for us,
have it write the test cases for us, intead of the future I'm cynically
seeing—where we write the test cases for AI written code.

[1] gopher://gopher.conman.org/0Phlog:2022/12/21.1
[2] gemini://thrig.me/blog/2022/12/22/unit-tests.gmi
[3] https://github.com/spc476/mod_blog/blob/67e97a769ea793f53a7be27f4b7568c5e102e758/src/wbtum.c#L147
[4] https://github.com/spc476/mod_blog
[5] gopher://gopher.conman.org/0Phlog:2022/10/08.1
[6] gopher://gopher.conman.org/0Phlog:2022/12/21.1
---

Discussions about this page

Another attempt at a “unit test” | Lobsters
  https://lobste.rs/s/t97f6e

Email author at sean@conman.org

.