On 02/25/2011 11:33 PM, Magnus Lie Hetland wrote:
On 2011-02-25 20:04:10 +0100, Jonathan M Davis said:
On Friday, February 25, 2011 07:30:50 Magnus Lie Hetland wrote:
Or, more generally, how do you test asserts (which is what I'm using in
my preconditions etc.)?
As far as I can see, collectException() won't collect errors, which is
what assert() throws -- so what's the standard way of writing unit
tests for preconditions that use assert? (I.e., test that they will, in
fact, throw when you break them.)
I think that the reality of the matter is the most of the time people _don't_
check them. And on some level, it doesn't make sense to. It's kind of like
asking how people test their unit tests. Unit tests are already testing code. Do
you want to be testing them on top of that? And if you do, do you test _that_
code? Where do you stop?
I guess so. But you could say the same thing about other cases where you throw
an exception when you detect that something is wrong -- but those are normally
tested, right? Also, the difference here is that the precondition is written as
a general "test", whereas my actual test would have specific cases.
For example, I have a test that checks that I don't add the same object twice
to some structure, and the check involves some traversal -- code that could
potentially be wrong. I wanted to make sure that it wasn't by explicitly adding
the same object twice -- code (i.e., my unit test) that most likely could not
be wrong.
But I do see your point.
Now that you speak of it, I do agree with you. Just like for code paths or
specific inputs that should throw an exception. I systematically check these
bits in unittests. It's very easy to have them right, if only by distraction
because they are not the points on which with we put most attention, and there
often is a test invertion somewhere (and we don't watch them run). And
actually, I often find an error somewhere in there.
What I do is trigger them in unitests, check all works as expected (ie an error
is raised, and the message is sensible), then comment out but /keep/ the
testing code.
Dunno if this makes sense for DbC checkings.
Denis
--
_________________
vita es estrany
spir.wikidot.com
