On 01/02/2008, Colin Jack <colin.jack@...> wrote:
> So I think I get your position now.
>
> You focus on testing behavior. Where this gets complex, because
> information is currently stored but not used in behavior, you test
> the end result (affect on GUI/other systems).

No.

I *start* with an automated end-to-end test of the desired *system*
behaviour that interacts with the boundaries of the system only
(client GUIs, events to/from from external systems, web-based reports,
etc.).

I then use unit-tests (with and without mock objects) to develop the
behaviour of the classes that implement the system-wide behaviour. If
that gets complex, I refactor the code to make it simpler to
unit-test. If information is stored but has no effect on the
behaviour of classes or the system as a whole, I delete it from the
system.

> The same presumably goes for the results of calls that return values.
> So if you are testing a method on a service/entity, and even if that
> method returned a value, you wouldn't directly test the value
> returned in a domain test. Instead you would verify that that the
> result is used in the correct way.

No. If a method returns a value, I test what it returns. But I do
try to minimise the number of methods that return values.

--Nat