Re: [MO-java-users] any pattern for this?

[J. X. <sou...@ma...>]

Quoting Steve Freeman <st...@m3...>:

> Of course you can do that, but that's a different technique. How much 
> this matters depends on your task, what you should be avoiding is the 
> sort of test that fails at the end but you can't quite see where, so you 
> have to step it through in the debugger. An advantage of MO tests is 
> that they fail when the error occurs.

You (and Nat as he pointed out the same) definitly have a good point.

> There are also interesting questions about how the test drives the code. 
> MO tend to push you towards defining types that talk about the 
> relationshps between objects, state tests push you towards exposing 
> state in your objects. Your call...

That sure is thought-provoking. One thing I have kept pondering on is *how 
much* I would like (or, rather, can afford) the test to drive the code. e.g., 
in this case, my code has had some strong assumption on the usage of castor. 
Would it then still be architecturally reasonable and natural to introduce an 
adapter that essentially duplicates the castor unmarshaller interface for the 
sole purpose of plugging in MO's?

--J.X.