Re: [Nmock-general] asynchronous testing

[Steve F. <st...@m3...>]

What I'm hearing from your comments is that mocklib is intended for 
different purposes from nmock, which is why it works better in those 
circumstances. Is there value to be gained from trying to merge the two 
approaches?

S.

On 25 Apr 2005, at 15:08, Dean Hiller wrote:
> Actually, the test is independent of the implementation(which allows 
> easier refactoring).  The implementation may fork a thread or not, and 
> the test will still pass.  The reason for forking occurs in many 
> systems for many different reasons(disk i/o, talking to a slow legacy 
> system through a stack, etc. etc.).  On my current project, I am 
> trying to write tests where I put a request to an api, and the 
> implementation drops it in a thread pool to go to my mocktransport.  I 
> am doing subsystem testing.  We do test first here, but we do 
> subsystem testing and integration testing.  We found subsystem testing 
> gets more bang for the buck.  It also results in very well defined 
> apis for the subsystems.  Lastly, it made refactoring of subsystems 
> much easier without rewriting tests.  Of course, this is just my 
> personal experience.   Some subsystems started out as just 3 classes, 
> and others grew into 10,000 lines of code(but the api is still pretty 
> small from the top(Low surface to volume ratio pattern).
> 	One other thing I liked about mocklib was I didn't have to learn 
> about isAnything(), isEquals()...instead, it returns the parameters to 
> you and you can do what you like with them.  Ie. I can do 
> assertEquals(expected, param1) and assertSame(expected, param2) 
> without learning more methods to use.  That would be kind of nice to 
> have.
> Thanks,
> dean