c# - When to use a Mock v. Stub, or neither? -
i've been reading on mocks , stubs, differences , uses. i'm still bit confused, think i've got jist of it.
now i'm wondering applications. can see use in creating "fake" objects in testing scenarios actual objects complicated haul around test 1 aspect.
but let's consider application: i'm working on computational geometry library. our library defines points, lines, linesegments, vectors, polygons, , polyhedra, along bunch of other objects , usual geometric operations. given object stored list of points or directions, or lower level objects. none of these objects takes more few milliseconds generate.
when i'm testing library, make sense use mocks/stubs anywhere?
right use particular test cases. we're calling them stubs, don't think meet technical definition of stub. think better vocab be? "testcases"? "examples"?
sourcecode: https://bitbucket.org/clearspan/geometry-class-library/src
edit: note we're striving immutability in our geometry objects, makes sense test results of operations, not state changes initial objects.
the fundamental difference between mock , stub mock can make test fail. stub can't. stub used guarantee correct program flow. never part of assert.
note mock can used guarantee flow. in other words, every mock stub, , stub never mock. because of such overlapping responsibilities nowadays don't see distinction between mock , stub , framework designers go more general terms (like fake, substitute or catch-all mock).
this realization (mock - assert, stub - flow) helps narrow down usage scenarios. start easier one...
mock
as mentioned mocks used in asserts. when expected behavior of component it should talk other component - use mock. those
emailsender.sendemail(email); endofdayrunner.run(); jobscheduler.schedulejob(jobdetails);
can tested asking "did call schedulejob
such , such parameters?" go mock. mock's usage scenario.
stub
with stub it's bit different. whether use stub or not design question. once follow regular loosely coupled, dependency injection-based design, end a lot of interfaces.
now, when in test, how return value interface? either stub or use real implementation. each approach has pros , cons:
- with library-generated stubs, tests less brittle might require more up-front work (setting stub , such)
- with real implementations, setup work done when
angle
class changescoordinatesystem
might fail... such behavior desirable or not?
is it? 1 use? both! depends on...
unit of work
we arrived @ final , actual part of problem. scope of unit test? unit? can coordinatesystem
detached inner workings , dependencies (angle
, point
, line
) , can stubbed? or more importantly, should be?
you need identify unit is. coordinatesystem
alone or perhaps angle
, line
, point
play important part of it? in many, many cases, unit formed both method , surrounding ecosystem, including domain objects, helper classes, extensions or other methods , other classes.
naturally, can separate them , stub way around then... unit?
Comments
Post a Comment