|We don't bite newbies here... much|
Re^6: Testing methodology (TAP++)by BrowserUk (Pope)
|on Mar 06, 2012 at 17:09 UTC||Need Help??|
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.
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! :)
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.