Well, I guess you haven't done much interesting unit testing?

Of course. That explains it. (yes. I can be just as sarcastic and dismissive as you. You know that. Why go there? <smaller>Knew it was too good to last.</smaller>)

But then, I don't really consider what you keep talking about as a unit test. It is a functional test ...

I tried to find definitions of 'unit testing' & 'functional verification testing' that I thought we might both agree on. As is, I couldn't find any from a single source that I could agree with. And cherry picking two from different sources to make a point would be pointless.

So, I'll state my contention in my terms and let you disagree with it in yours.

Your style of unit testing -- in my terms; laborious, verbose and disjointed -- will not discover anything that my style of unit testing -- in your terms perhaps; functional verification -- will fail to highlight.

But my style of UT will discover every failure that your style might. And much, much more. Therefore, your style of UT is incomplete without some of my style of UT.

Therefore, your style of UT is redundant. A cost for no benefit. Make-work.

You will (have) argue that your unit tests help you track down trivial programming errors -- your cited example off-by-one errors. My contention is that, with the right configuration, my style of UT allows me to track them down just as effectively. Eg.

C:\test>perl async\Q.pm -N=10 -T=2 -SIZE=10
1
2
3
4
5
6
7
8
9
10
10 items by 2 threads via three Qs size 10 in 0.030158 seconds
[download]

I added a single print to the dq loop. (Actually put back; as it was there to start and was removed once proven.)

And I configured the test for 2 threads. Which means that each of the two "pools" gets one each. Thus, the ordering from Q1_n via Qn_n and Qn_1 is deterministic.

So, I started with the simple case, and only increased the workload once the basic functionality was working. I removed the print to kill the (now redundant) noise.

One set of tests to write (and maintain!) that serves both purposes. Cheaper and more cost effective.

And here is the kicker.

The code I posted contains a (quite serious) bug -- put back especially for the purpose.

And the challenge -- which you won't take -- is that no amount of your style of UT testing will ever detect it!

My style of UT makes it trivial to find. (And no, it is not a subtle timing issue or freak lock up or anything else that you can blame on "threading").

Just a plain ol' coding bug.

Betcha can't? (Know you won't! :)