How do you test pre-/post-conditions and invariants?

[spir]

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