Re^4: Neither system testing nor user acceptance testing is the repeat of unit testing (OT)

Since you've thrown down the gauntlet, let me pick it up.

You present a false dilemma, suggesting that you only get to do one kind of test. And then you present an argument that black box unit tests should be more important.

But the fact is that you can do both. And they pick up different kinds of errors. I fully agree that all of the tests of the basic interface should be motivated by the interface specification, not the implementation. That is, they should be black. But corner cases and special cases in the code are a common source of bugs, and that one may only reliably figure out where those cases actually are by staring at the implementation. (One may guess without peeking, but one only knows after looking.) So including white box unit tests to smoke out possible bugs in corner cases catches errors that black box testing may not.

Therefore after you write your black box unit tests, there is value in adding white box tests as well. Given a positive return from doing the work, one should do it.

This is also why white-box measurements such as coverage percentage (see Devel::Cover) have value.

UPDATE: minor punctuation and added "white-box" to the last sentence to clarify my point.

Comment on Re^4: Neither system testing nor user acceptance testing is the repeat of unit testing (OT)

Replies are listed 'Best First'.
Re^5: Neither system testing nor user acceptance testing is the repeat of unit testing (OT) by dragonchild (Archbishop) on Oct 24, 2005 at 13:17 UTC
This is so funny. I feel that your argument against my point only ends up supporting it. "corner cases and special cases in the code" are very much a common source of bugs. However, I think that having corner/special cases is a CodeSmell. (Yes, I'm being idealistic here - there is no application whose code smells like roses.) Plus, imho, Devel::Cover is a measurement of the success of your black-box tests vis-a-vis your interface. If you have lines of code you don't have tests for, that's a problem that needs to be addressed. Granted, you might address is by looking at the code to see which interface components either haven't been tested or have been over-coded for. But, that doesn't mean the test suite has necesssarily become white-box. I often use coverage to both learn more about my interface and to remove code that shouldn't have been there in the first place. Still black-box. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^6: Corner cases are not always "code smell" by Ovid (Cardinal) on Oct 24, 2005 at 17:59 UTC
I think that having corner/special cases is a CodeSmell. That depends upon what those corner cases are. Sometimes it is impossible to avoid them because the real world does not behave the way we want it to. A common example would be leap years. You have to have corner cases there. In fact, there are a lot of corner cases in date handling due to how tricky it can be. Also, hourly employees generally get time and a half if they work more than a set number of hours per week, but for some states/countries, they can also get time and a half if they work more than a set number hours per day. Those are exceptions to the rule and, as such, may get special treatment in the code. Or how about removing data from a database? Many systems merely mark the data as "deleted" buy don't actually delete it so that it can be recovered. However, there may be legal reasons why the data must be deleted (for example, contractual agreements). This may come up as a "special case." Many issues which may be a corner case can be developed in such a way that they're not a corner case (deleting database records, for example), but whether or not it's practical to do so depends upon the needs of a given application. Cheers, Ovid New address of my CGI Course.	[reply]
Re^7: Corner cases are not always "code smell" by Roy Johnson (Monsignor) on Oct 24, 2005 at 18:06 UTC
Code Smell: Note that a CodeSmell is a hint that something might be wrong, not a certainty. A perfectly good idiom may be considered a CodeSmell because it's often misused, or because there's a simpler alternative that works in most cases. Calling something a CodeSmell is not an attack; it's simply a sign that a closer look is warranted. Caution: Contents may have been coded under pressure.	[reply]
Re^7: Corner cases are not always "code smell" by dragonchild (Archbishop) on Oct 24, 2005 at 18:13 UTC
While Roy is certainly right in the definition of CodeSmell, I'd also like to point out that those corner cases are corner-cases in the spec, not the code. Reality has corner cases, code doesn't. If you run into one (leapyears, overtime, data retention), that needs to be documented in the spec and the tests first, then in the code. Except, once it hits the code, it's not a corner case - it's a requirement. That may sound like semantics, but I think it's an important distinction. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^8: Corner cases are not always "code smell" by tilly (Archbishop) on Oct 24, 2005 at 21:31 UTC
Re^9: Corner cases are not always "code smell" by dragonchild (Archbishop) on Oct 25, 2005 at 13:49 UTC
Some notes below your chosen depth have not been shown here
Re^8: Corner cases are not always "code smell" by Anonymous Monk on Oct 25, 2005 at 03:07 UTC


Clear questions and runnable code get the best and fastest answer
	PerlMonks