[kleigenfreude]

Some feedback for the OP:

1. The tester and another team member spent a year developing something that would intercept calls and relay them. Two problems with that: (1) two person years spent, (2) and that sounds like serious NIH (not invented here) syndrome. The problem that should have been solved was everyone spending the time to write better tests and changing code as needed. Instead, they spent a year on a workaround, invented in-house. Was there not anything else out there that did this?

2. The word is "focused", not "focussed".

3. Lack of detail: how exactly does it work beyond that basic diagram?

4. Where's the code for the project? Would it be useful to others?

However, I admire that the OP posted their experience, and it is useful information.

[sampullman]

I believe "focussed" is acceptable, although "focused" is preferred in the US.[1][2]

Can you explain why this sounds like serious NIH syndrome? It looks like they built a system to cache service requests on top of an existing test framework. It seems specific enough that there might not be an existing method that fit well enough. The article is a bit light on details though, so I suppose it's hard to tell.

[1] https://en.wiktionary.org/wiki/focussed [2] http://dictionary.cambridge.org/dictionary/english/focused

[jochenw]

OP here ;-) 3 and 4: The article isn't at all about the tool we built, it's supposed to shine a light on the different kinds of tasks that Test Engineers do. Think of it as not very subtle job advertising.

1. The idea was definitely out there (some other commenter posted a link to pacts, which were a strong influence). Part of the process (and I hope this comes out in the article) was to try to find good ways to write better tests. We couldn't really (long story, let's just say "legacy code" to summarize it). So in the end we went for this technique. The whole process took a year to do, and as far as NIH goes, the existing implementations do not work in Google's setting. So we had to roll our own implementation. That did not take very long, though.

[danielsju6]

2 man years is nothing at Google scale.

You're asking that every engineer at Google spend more time writing better tests? What's the math end up saying there? That if each engineer spend more than X minutes per year writing better tests, there would be an ROI. Where X ends up being a comically low number.

And you'd still probably want caching system at scale anyway, esp. given a monorepo. Think compute hours saved.

NIHS, as you're calling this, can often make sense at scale.