Hacker News new | past | comments | ask | show | jobs | submit login

One of the most obvious problems with mocking is that the team that develops some code usually also develops the mocks that are used for testing it. So precisely the same misunderstandings will be present in the code as in the mocks. In other words you are not really testing anything.

From my experience most errors are at boundaries between code from different teams. Mocking does not help here.

My favorite form of tests are what I usually call subsystem tests. Try to test as much code as is feasible with each single test.

Usually there are parts of your system that can be expensive to setup or use. For example, creating and filling a real database can be slow. In this case you could use an in memory database. Creating it and filling it with some representative data can be very fast. This database could be used by multiple teams, and is vastly superior to mocking.

A similar approach can be used with other expensive parts like remote procedure calls [0], or input from browsers.

This approach works when you design your system so that it can easily switch between using the real (expensive) resources and the ones that are only used for testing. But that is not very difficult.

[0] Both REST and SOAP are RPC




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: