>Phil, if your objetive if detecting errors as early as possible, you should
>try harder to detect them before the program is used by your clients. A very
>good way to do this is providing a more comprehensive set of tests.

You're right, of course. That's not an either-or solution though. It's
complementary. You can (and I think should) do both.

>Tests are also a much more better way to document your model 

It's not obvious to me why tests are even slightly better for documenting
a model, never mind much better. I run tests, I don't read them. I read
code as I maintain it. Assertions in code help me understand the system's
expected state and behavior.

>and they don't
>introduce extra-complexity, 

I guess this might be a matter of perception and familiarity (which is
not to discount them as complexity factors). I don't think assertions
really add complexity; I'd say they add robustness and clarity. To
someone who is comfortable with them, an assertion is a sign of well-
designed, well-implemented code. I can always tell which of my own code
is quick-and-dirty by the lack of assertions.

>nor a performance penalty.

That's a definite problem with Object>>assert: but I've worked around it
using the State design pattern and indirection to globally switch off
assertion evaluation. When evaluation is switched off, the only
performance hit is method lookup and dispatch.

At base, the philosophy behind assertions comes down to one thing: a
programmer who can say "I make mistakes" and really mean it and really
believe it and not suffer a total ego meltdown in the process, will find
assertions are a great help. Not "I can make mistakes". Not "In theory, I
make mistakes". Not "I used to make mistakes". Not "I make mistakes, but
they're not serious". Just "I make mistakes". It's like dealing with
alcoholism: first thing is to admit that one has a problem. 

For those who don't make mistakes, assertions are a complete and utter
waste of time and I would strongly advise against their use. :-)