[Pharo-dev] Unifying Testing Ideas

Sean P. DeNigris sean at clipperadams.com
Tue Dec 3 11:25:14 EST 2013


Attila Magyar wrote
> did you want something like this?
> mock a: anyArgument b: exactArgument1 c: exactArgument2

Exactly.


Attila Magyar wrote
> I rarely use 
/
> does
/
> , as far as I remember it is not even documented. I don't know the code
> behind the test but based on the names it looks like an adapter like
> thing. (e.g. a thin wrapper above a 3rd party api with not too much logic
> inside). If this is the case, normally I would test it with integration
> tests, instead of mocks.

Yes it's a wrapper. It should be tested with integration/acceptance tests.
But, it wraps callouts to a C dynamic library via NB, so it's hard to test -
i.e. crashes the VM, etc. Interactions with it deserve to be tested via unit
tests (in general I drop down to unit tests inside a failing
integration/acceptance test anyway). 

Anyway, does: is very important. Stubbing (can & (does: | answers:)) and
mocking (should) seemed kind of like a nature-vs-nurture debate for a while,
but there is a lot of overlap. Sometimes you need one, sometimes the other,
and sometimes both (as shown in my example, although I kept thinking that in
practice I'd probably write a test double by hand to be reused in other
places).

In fact, #does: and #answers: could easily be merged, using double dispatch
to pass either a block or a value.

Unrelatedly, it would be slightly clearer to rename "anything" to
"anyMessage". "anything" makes it seem like it could be passed as an
argument, which doesn't work. Or alternately, you could probably rename
AnyMessage to Anything and combine its API with that of AnyArgument if they
don't clash...



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Unifying-Testing-Ideas-tp4726787p4727086.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.




More information about the Pharo-dev mailing list