Manuel,

--- In extremeprogramming@yahoogroups.com, "Manuel Klimek" <klimek@...>
wrote:
>
> To jump in: The root cause acceptance tests solve for me is that:
> - I do forget to write unit tests for corner cases, even if I try to
> do TDD, probably because I suck at TDD.
> - I am too stupid to write good unit tests for many multi-threaded
> things I write.
> - I am too stupid to remember what I thought yesterday; so I sometimes
> use mocked out components thinking "oh, yea, this value cannot be
> zero", and later implement the component, thinking "why not just
> return zero here?". Boom.

Is it easier to cover corner cases at the acceptance level than the unit
level? We have experienced the opposite, as corner cases at the unit
level lead to combinatorial explosions at the top level.

The only time we throw something off into another thread is fire and
forget... we don't have race conditions.

> So they address my risk-averseness: multiple layers to protect me from
> my own stupidity.
> I think if you don't see the need for acceptance tests, you're smart,
> or lucky, or not writing very complicated code. If one of your
> acceptance criteria is "thousands of users must be able to furiously
> misuse your system at the same time", and you say you do not need
> acceptance tests because you do not introduce regressions to that, I
> bow to you.

We don't have a system where thousands of users must be able to
furiously misuse it at the same time.

The system in question is used in thousands of companies but it is an
expert system so only used by a few people at most locations.

It's a fairly complex system but that's like saying the weather here is
fairly nice. What does that mean?

Let me be clear, I am not advocating anyone give up acceptance testing.
And I am not saying "we are so smart we don't need them." Very clearly
let me state, we are who we are... regular developers... and somehow we
have managed to do what everyone says can't be done. I don't know why
and I want to know.

Matt