4 ms·
Mocks are worthwhile though. Otherwise you end up not being able to unittest anything which accesses an external api such as databases, rest services etc.
by 411111111111111 6y ago
Mocks are worthwhile though. Otherwise you end up not being able to unittest anything which accesses an external api such as databases, rest services etc.
- deleted 6y ago[deleted]
- Joker_vD 6y agoYou mean fakes/stubs, right? Unless you're testing whether you're correctly implementing the protocol exchange with an external party, you don't need to record the API calls.
- mumblemumble 6y agoIt really depends on your definition of unit. In the London school of TDD, no, a unit cannot extend across an I/O boundary. The classicist school takes a more flexible, pragmatic approach.
- the_other 6y agoI'd love to know the story behind "the London school".
- insertnickname 6y agoIt's all in this book: http://www.growing-object-oriented-software.com/ http://www.growing-object-oriented-software.com/
- the_other 6y agoIntriguing. Thanks!
- matkoniecz 6y agoI have plenty of tests actually calling database. Maybe it is not a proper unit test, but it is not a problem for me. I want test to protect me against regressions, and I do not really care how they are classified.
- mannykannot 6y agoHow do you test your mocks?
- jacobsenscott 6y agoHow do you test the tests that are testing your mocks? That said verifying mocks are a great help - they won't let you mock methods that don't exist on the real object. Some mocking libraries, like the VCR library in ruby, can be turned off every now and then so you tests hit real endpoints. It is worth doing from time to time.
- dagss 6y agoIMO, databases is often an integral part of the program and should be part of the test (a real database in a docker image). For instance, if you are not relying on unique constraint in the DB to implement idempotency you are probably doing something wrong, and if you are not testing idempotent behaviour you are probably doing something wrong.