Page 1 of 1

Unit test to validate sequence of method calls

Posted: Fri Oct 02, 2009 1:04 pm
by alex.barylski
This is my understanding of what BDD would offer, in setting expectations, such as asserting that a sequence of methods are invoked in a certain order.

I have read that article by Fowler 'Mocks Aren't Stubs' and I partially share his sentiment about creating tests that are to tightly coupled to implementation in this regard (that is if I understood him correctly) however in this case, the code would potentially break if the order of invocation was changed, so perhaps writing a spec to assert this expectation wouldn't be a bad idea???

I'm writing this really quickly so I apologize if it doesn't make sense, I'm just having a brain dump moment :P

Cheers,
Alex

Re: Unit test to validate sequence of method calls

Posted: Fri Oct 02, 2009 8:10 pm
by josh
PCSpectra wrote: the code would potentially break if the order of invocation was changed, so perhaps writing a spec to assert this expectation wouldn't be a bad idea???
Possibly yeah your code could break, but think about the ways in which it can "break", can you test for those conditions? In my opinion as long as the proper return values are generated, without exceptions or errors, the code didn't "break" and a test telling you otherwise is a brittle test which is a "test smell". For instance maybe there are 5 method calls but only 2 of them depend on calling order, a) rather then having to figure this out, and b) figure out how to specify it in a test you could just test for the proper return values, then later [if/when] you mess with that code you have the flexibility to change more code than if you had tested the implementation.

For instance if you call you methods in order 1,2,3,4,5 and later spot that by calling them in orders 1,2,4,3,5 you get some benefit from an extensibility standpoint, your test should not fail just because you re-organized code ( Unless it was reorganized in a way that changed the return values! ). Maybe you originally were right that it had to be called all in order, maybe not... or maybe other code changed which changed that. why spend the time figuring that out now though?

Like maybe changing the order of the calls means a log file doesnt get created, so test that the log file gets created, that way your test tells you in English "log file not created", rather then "xyz configurator called in wrong order" ( which could mean 10,000,000 other things other then the log file.. leaving you to do further debugging.. ugh )... think plain English, not implementation... 1 granular condition per test

I would only try to test implementation for certain classes, like "system boundaries", like testing the DOC log class you might want to test it's outbound calls to a stream class if the real logging action is expensive, wether you do this via mock's with "expected" calls or stubs is not what you were asking, I think..

Re: Unit test to validate sequence of method calls

Posted: Mon Oct 05, 2009 9:28 am
by Jenk
There are some cases where it's impossible to not test implementation, such as a Translator or Decorator/Wrapper test, or even when testing a Protocol.

Though personally I'd be testing that exceptions are raised when improperly used before testing that "it works" when used properly.

Re: Unit test to validate sequence of method calls

Posted: Mon Oct 05, 2009 4:22 pm
by josh
Why before?

Re: Unit test to validate sequence of method calls

Posted: Tue Oct 06, 2009 7:57 am
by Jenk
To avoid the "Ah, it works. Now I don't want to touch it." :)

Also because I think it's more important functionality - that improper use is flagged. :)

Re: Unit test to validate sequence of method calls

Posted: Thu Oct 08, 2009 11:19 am
by josh
good reasons