Hi, cool to have a taxonomy of stubs, mocks and all. Question :
* what is 'dummy' about the first object ? Isn't that simply calling the method with a valid argument ?
* the second examples implicitly shows a design decision : the ItemPricer interface must exists at all. This has two nice consequences : first the ShoppingCart codes tends to become trivial (simply calling out methods in dependencies in a nice order) ; second, it becomes possible to concentrate one one implementation of ItemPricer that has all the tricky logics.
My question is : at some point, doesn't the ShoppingCartTest come become much more complicated to write than the logic code ? At wich point does it become intersting to 'forget' some test code that would just do wiring between its dependencies ? Any experience with that ?
* The spy example assumes that ShoppingCart communicates with the outer world, doesn't it ?
On the overall, it is only possible to invite such friends if you code has been prepared in the first place. To keep the analogy, it requires a friend room and some beers in the fridge. How do you tester guys manage to get those design decisions made early enough (and probably by other developpers) so that test code is easy to write ?
This comment has been removed by the author.
ReplyDeleteTo help the less test-savvy it would have helped to point out exactly which thing is the stub, fake, etc.
ReplyDeleteHi, cool to have a taxonomy of stubs, mocks and all. Question :
ReplyDelete* what is 'dummy' about the first object ? Isn't that simply calling the method with a valid argument ?
* the second examples implicitly shows a design decision : the ItemPricer interface must exists at all. This has two nice consequences : first the ShoppingCart codes tends to become trivial (simply calling out methods in dependencies in a nice order) ; second, it becomes possible to concentrate one one implementation of ItemPricer that has all the tricky logics.
My question is : at some point, doesn't the ShoppingCartTest come become much more complicated to write than the logic code ? At wich point does it become intersting to 'forget' some test code that would just do wiring between its dependencies ? Any experience with that ?
* The spy example assumes that ShoppingCart communicates with the outer world, doesn't it ?
On the overall, it is only possible to invite such friends if you code has been prepared in the first place. To keep the analogy, it requires a friend room and some beers in the fridge. How do you tester guys manage to get those design decisions made early enough (and probably by other developpers) so that test code is easy to write ?
Thanks for the ToT series, keep up the fun !
Regards
PH
@Pierre-Henri Trivier: This taxonomy of stubs is also presented in the great "xUnit Test Patterns" book.
ReplyDelete