![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Orchid XP v8 <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |