3

I've always been taught that your tests should run in isolation, and other than a db for ActiveRecord etc., your tests should not rely on any external software/services. e.g. I always mock my other web-service responses but what about responses from web based key-value stores and aggregators like elasticsearch, redis, and statsd? My intuition would be to mock those as well as I am not testing if they work I am testing my apps IO with them. However I see examples around where people uses namespace strategies to test their elasticsearch and statsd related code.

How much should I mock when it comes to web based services?

thanks!

kreek
  • 317
  • 1
  • 10
  • 1
    Here's a relevant blog post: http://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html – Jules Dec 09 '14 at 19:00

2 Answers2

4

Treat them as an ordinary database.

When you are testing business code which uses a database, you mock the database in order to test just the business code (as well as for making tests slightly faster). The same applies to key-value stores.

What you may have seen is:

  • Either integration and system tests which, indeed, rarely use mocks. Usually, a system test will run with a database filled with test data. Some system tests may even use third-party web services (some system tests may still mock those web services if you pay per request).

  • Or simply unit tests written by a person who is unaware of proper testing techniques.

Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
1

Mocking serves a number of purposes:

  • make the test run fast
  • make sure all services required by the test are always available
  • make sure defects don't make debugging your module too complicated

If none of these is a substantial problem in your case, don't mock.

Why not? Because

  • creating mocks costs time
  • mocks induce additional effort when changing your own module's internals (white box testing)
  • your mock may lie to you about what the real module actually returns
Lutz Prechelt
  • 1,483
  • 9
  • 11