I think Ovid gave perfect examples to disprove his point. Those are all corner cases that need to be in the spec and so could be subject to black-box testing.

However, I don't agree with the extreme point of view that every corner case needs to be in the spec. Because... You Are Not Going To Need It.

If you spend all of your time gold-plating and turd-polishing your spec, then you run into the same problems with doing that to your code.

We save a lot of time by leaving a lot of corner cases unspec'ed because they are implementation details and whether X or Y happens in that corner case is not going to matter for 99.9% of them. The 0.1% of cases where a corner case that was found during implementation mattered in the finished product are caught in other phases of testing or based on judgement. Most code corner cases don't need the attention of revisiting and rehashing the spec.

But we test those corner cases in our unit tests. Usually we either want the corner case to blow up (so we know when it becomes a case that matters) or we want to make sure it doesn't blow up (because the outcome doesn't matter but you want to know that the code doesn't contain a stupid and fatal mistake just in case the "impossible" isn't as impossible as first thought).

Corner cases do not always mean extra code. If the only corner cases in code were places where you could just remove the code for that corner case because You Are Not Going To Need It, then you could almost make your high-ground claim of "no corner cases unless in the spec" (other than optimizations, as tilly pointed out).

That is why languages have "undefined" behaviors. Because it is a huge waste of time to over-specify every tiny detail of behavior such that you've completely tied up the hands of the implementors for the sake of guarantees that don't matter (except they matter now because your implementation sucks because it is forced to meet the micro-managing spec).

And yet, part of the spec is that the language never dumps core. So you need to test every line of code even though some of those lines were a means (implementation detail) to an end (spec'd requirement).

In reply to Re^8: Corner cases are not always "code smell" by Anonymous Monk
in thread Neither system testing nor user acceptance testing is the repeat of unit testing (OT) by pg

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.