Thinking on it a bit, it sounds like unit testing is just a way to add 
Eiffel-style programming-by-contract to your code without any actual 
language support for it.
-- 
Darren New, San Diego CA, USA (PST)
    Ada - the programming language trying to avoid
    you literally shooting yourself in the foot.

Post a reply to this message

Darren New wrote:
> Thinking on it a bit, it sounds like unit testing is just a way to add 
> Eiffel-style programming-by-contract to your code without any actual 
> language support for it.

I thought the term was "design by contract"?

Well whatever. Contracts seem like a nice idea; you make it clear who's 
supposed to check for error conditions - whether it's supposed to be the 
caller or the callee. And you can enforce it by enabling checks at 
runtime. Having said that, I don't recall using it much myself in my own 
code.

On top of that, any kind of testing is going to be easier if a 
function's output depends only on its current inputs...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Darren New wrote:
>> Thinking on it a bit, it sounds like unit testing is just a way to add 
>> Eiffel-style programming-by-contract to your code without any actual 
>> language support for it.
> 
> I thought the term was "design by contract"?

Yeah. Brain-O.

> Well whatever. Contracts seem like a nice idea; you make it clear who's 
> supposed to check for error conditions - whether it's supposed to be the 
> caller or the callee. And you can enforce it by enabling checks at 
> runtime. Having said that, I don't recall using it much myself in my own 
> code.

Yep. Every time you use "assert" to check your inputs, you're doing that. 
Except with minimal language assistance.

Unit testing just takes those asserts outside the function.

> On top of that, any kind of testing is going to be easier if a 
> function's output depends only on its current inputs...

Yep. The problem with "unit testing" per se is that it only tests a unit. It 
doesn't test anything except the invariants of the unit you're testing.

-- 
Darren New, San Diego CA, USA (PST)
    Eiffel - The language that lets you specify exactly
    that the code does what you think it does, even if
    it doesn't do what you wanted.

Post a reply to this message

Darren New wrote:

> Yep. Every time you use "assert" to check your inputs, you're doing 
> that. Except with minimal language assistance.

Eiffel has preconditions *and* postconditions, which most people don't 
seem to bother checking with assert() calls.

> Unit testing just takes those asserts outside the function.

Whilst Haskell does have an assert() function, it seems to be more 
popular to use QuickCheck.

QuickCheck does automated randomised testing. Give QC a property that's 
supposed to hold for any inputs, and it generates inputs at random and 
checks whether the property holds.

The big snag, of course, if that if your code fails only under very 
specific, rare circumstances, randomised testing might not hit the bug. 
(This is why books on testing talk about testing limits, flow control 
paths, etc.)

Also, asserts or design by contract will catch the source of a crash in 
a live running program. (Assuming that enabling the tests doesn't slow 
the program to the speed of a glacier...)

>> On top of that, any kind of testing is going to be easier if a 
>> function's output depends only on its current inputs...
> 
> Yep. The problem with "unit testing" per se is that it only tests a 
> unit. It doesn't test anything except the invariants of the unit you're 
> testing.

I thought the idea was that you then combine several units into a larger 
unit, and test that (and so on, recursively). Then again, maybe that's 
what they mean by "integration testing"...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Eiffel has preconditions *and* postconditions, which most people don't 
> seem to bother checking with assert() calls.

  A little thought experiment: How would you write a comprehensive
postcondition to a function that sorts a list/array of elements?
(Assume there is no reliable third-party sorting function available.)

-- 
                                                          - Warp

Post a reply to this message

>   A little thought experiment: How would you write a comprehensive
> postcondition to a function that sorts a list/array of elements?
> (Assume there is no reliable third-party sorting function available.)

Sorting a container is at best O(n log n), but determining whether one 
is already sorted is only O(n). :-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:

>   A little thought experiment: How would you write a comprehensive
> postcondition to a function that sorts a list/array of elements?
> (Assume there is no reliable third-party sorting function available.)

Here's a better one: You write a compiler. How the **** do you determine 
whether it actually works properly? (!)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >   A little thought experiment: How would you write a comprehensive
> > postcondition to a function that sorts a list/array of elements?
> > (Assume there is no reliable third-party sorting function available.)

> Sorting a container is at best O(n log n), but determining whether one 
> is already sorted is only O(n). :-)

  Hmm, that's not what I asked.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 wrote:
> Darren New wrote:
> 
>> Yep. Every time you use "assert" to check your inputs, you're doing 
>> that. Except with minimal language assistance.
> 
> Eiffel has preconditions *and* postconditions, which most people don't 
> seem to bother checking with assert() calls.

Yes. The postconditions are checked with unit tests. And people try to check 
invariants that way too. And unit tests generally don't try to check loop 
invariants.

> QuickCheck does automated randomised testing. Give QC a property that's 
> supposed to hold for any inputs, and it generates inputs at random and 
> checks whether the property holds.

Again, you're checking invariants, which I find is usually not that useful.

> I thought the idea was that you then combine several units into a larger 
> unit, and test that (and so on, recursively). Then again, maybe that's 
> what they mean by "integration testing"...

Yes, that's integration testing.  Then there's "functional testing", where 
you test the program does what the customer actually wants. Then there's 
system testing, where you make sure the program does what the customer 
actually wants even when interacting with other code (basically).

-- 
Darren New, San Diego CA, USA (PST)
    Eiffel - The language that lets you specify exactly
    that the code does what you think it does, even if
    it doesn't do what you wanted.

Post a reply to this message

Warp wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>> Eiffel has preconditions *and* postconditions, which most people don't 
>> seem to bother checking with assert() calls.
> 
>   A little thought experiment: How would you write a comprehensive
> postcondition to a function that sorts a list/array of elements?

Trivial.

Forall(i < length-1) assert(j[i]<=j[i+1]);

Basically, the definition of sorting. Of course, you need to be able to put 
qualifiers in your assertions.

-- 
Darren New, San Diego CA, USA (PST)
    Eiffel - The language that lets you specify exactly
    that the code does what you think it does, even if
    it doesn't do what you wanted.

Post a reply to this message