Hacker News Reader

Comment by sly010 | Hacker News Reader

In a large graph you would re-test the same part of the code over and over, because many top level inputs is going to do trigger the same code-path deep down in the graph, which is wasteful. In a sense they memoize service call answers, so any tested code-path only needs to run once.

If they actually do this across their code they will never have to run "real service calls", because those services are also tested the same way. It's mocking all the way down.

View on HN

Paraphrasing the famous quote: There are only two hard problems in CS: naming things and cache expiration.

An issue I see with this is that there's a potential window when tests pass with bad data. For example, tests using a mock and the mock is periodically verified with a service call. The mock could become bad data, but won't be marked as bad until the next service call verification. Until that happens, the tests using the mock will all pass. It's not clear from the article how they address this.

... and off-by-one errors.

Perhaps Google tracks the changes to the dependencies, and reruns tests against a a real service when it changes.

That's how I would do it, at least.

If you have task-oriented build system with dependencies (like Google does with Blaze), it'd fit right in.

Though depending on how you deploy, you may have old and new services at different versions. Assuming a level backwards/forwards compatibility may be reasonable.

I imagine that if the service call to verify mock data fails, it should retroactively invalidate all tests based on that mock data, or at least this should be understood to be the case by the people reviewing test reports.

Reply on news.ycombinator.com