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 changes coordinatesystem 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

Popular posts from this blog

PHP DOM loadHTML() method unusual warning -

python - How to create jsonb index using GIN on SQLAlchemy? -

c# - TransactionScope not rolling back although no complete() is called -