Google Testing Blog

I love the Google Testing Blog https://testing.googleblog.com/

This article relates to two classic principles: 1. Avoid long parameter lists [1] 2. Avoid boolean arguments [2] For #1, long parameter lists should be named (named arguments, options object, etc). For #2, and booleans should be replaced by meaningful enumerations. > toggleMenu(true); That’s clear enough. the meaning is obvious Actually, it's incredible ambiguous. Is that toggling the menu? Or setting it to the open state? Or something else? I have no idea. setMenuState(MenuState.OPEN) setMenuState(MenuState.CLOSED) [1] https://testing.googleblog.com/2024/05/avoid-long-parameter-list.html [2] https://alexkondov.com/should-you-pass-boolean-to-functions/

This one is a classic, Avoid the Long Parameter List https://testing.googleblog.com/2024/05/avoid-long-parameter-list.html

I believe pretty strongly in the "testing pyramid" - that you should have a broad base of unit tests, with fewer integration tests and even fewer e2e tests. Source (also from Google): https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-… I think good unit test coverage is essential for good maintenance, but you can't cover _everything_ with unit tests. You definitely need integration and e2e tests to ensure bigger picture correctness. I have found that value one gets out of the different kinds of tests as you proceed up the pyramid get higher the closer to release you are, and are most valuable post release. During development they become obsolete too quickly due to changes in how things work. But locking in an already-released version to avoid regressions is great.

This conclusion doesn't, at all, follow from the premise. While yes, nit-picky review could mean the reviewer doesn't understand the big picture, an LGTM with no comments at all is more likely to be indicative of missing something. What you really mean is that nit-picky reviews that don't pick up on actual logic or functionality issues are a smell. Which is true, but isn't usually the case at Google[0]. The chapter on teamwork covers some relevant concepts (like psychological safety). [0]: https://testing.googleblog.com/2018/05/code-health-understanding-code-…

Another one for Google that's really interesting is their testing blog: https://testing.googleblog.com/

Sort of, yeah. See https://testing.googleblog.com/2017/04/code-health-googles-internal-co… as one of the examples of a type of Engineering Productivity work that I do at Google (although as you have basically pointed out, there are reasons we avoided that word for the work that I do, although I still think it falls under the broader umbrella). It seems like the thing that you're worried about (I mean, correct me if I'm wrong, this is just the sense I get from your post) is people hiring a sketchy consultant to come in and have everybody follow some process whether or not it has anything to do with their work or making things actually better. I'm definitely also opposed to stuff like that and I've made a few jokes or snide comments about it here and there on the blog, in http://www.codesimplicity.com/book/, and on my Twitter feed.

TIL TotT is externalized. https://testing.googleblog.com/

Your integration test needed the system that you were integrating with, so you'd have to declare that as a dependency. My philosophy was to always have integration tests run in the normal CI system. This basically meant creating a test binary that happened to link in the systems you were integrating with, and run tests against that. This is easier when everything is written in the same programming language, and for the cases where it wasn't, I was usually happy with "fakes". (https://testing.googleblog.com/2013/06/testing-on-toilet-fake-your-way… Other teams really loved the sandbox environment with live instances of everything. They would have some machinery outside the standard CI system to inject their code into this sandbox and run some tests, as well as machinery for keeping their sandbox up to date with production. (And adding test data, etc., etc., which all becomes very complex very quickly.) Both methodologies have their downsides and upsides. I generally prefer simplicity and speed; people should be able to run the tests on their workstation 100% of the time without having to set up any external resources. If you have an integration test binary that is built from the build system, this is possible. The downside is that config changes in production can break your system; since you are starting up your own instance of some other team's server, they could theoretically make some config change that breaks your integration. Even if you include their…

The concepts of Semantic Functions and Pragmatic Functions seem to be analogous to a Functional Core and Imperative shell (FCIS): https://testing.googleblog.com/2025/10/simplify-your-code-functional-c… The key insight of FCIS is that complicated logic with large dependencies leads to a large test suite that runs slowly. The solution is to isolate the complicated logic in the functional core. Test that separately from the simpler, more sequential tests of the imperative shell.

Google Testing blog: https://testing.googleblog.com/2025/10/simplify-your-code-functional-c…

https://testing.googleblog.com/2021/04/mutation-testing.html https://research.google/pubs/state-of-mutation-testing-at-google/

Hence why Google has Sensenmann to reap dead code: https://testing.googleblog.com/2023/04/sensenmann-code-deletion-at-sca…

If you construct an object once, then what is the difference between that and a singleton? The answer is scope. Singletons exist explicitly for the purpose of violating scoping for the convenience of not having to thread that dependency through constructors. https://testing.googleblog.com/2008/08/root-cause-of-singletons.html

https://testing.googleblog.com/2015/01/testing-on-toilet-change-detect… "speaks volumes" lol

I think one of the biggest issues is the definitions we use. Some developers would call mock any kind of double that replaces dependencies. Other developers define mocks as doubles that verify interactions with the dependency (interaction testing [0]). In this case the author mentions mocks and spies, therefore he's referring to "interaction testing". In other words, tests that verify that the dependency was called in the "right" way. If you own those dependencies, and later you refactor them you'll also need to refactor any test that used "interaction testing". If every time that you want to refactor a dependency you break a ton of tests, then refactoring becomes a tedious and sometimes difficult task. [0]https://testing.googleblog.com/2013/03/testing-on-toilet-testing-state…

One random thing I've been impressed with (that I know is public) is mutant testing: https://testing.googleblog.com/2021/04/mutation-testing.html , https://research.google/pubs/pub46584/ To pull an example from the paper, if your line of code says if (a == b || b == 1) you might get a comment that says something like > "Changing this line to if (a != b || b == 1) > does not cause any test to fail." Page 4 lists other mutations, like replacing logical ANDs/ORs with just `true` or `false`, switching arithmetic plus to minus, etc. This isn't a larger system design context thing, though, just a testing one. Disclosure: I work at Google.

This is so important but even most professional software developers and testers don't seem to understand it. Tests are not supposed to break on every little change to the code, or even sweeping changes in implementation. If they do, they're not very good test. https://testing.googleblog.com/2013/08/testing-on-toilet-test-behavior… https://medium.com/expedia-group-tech/test-your-tests-f4e361818720

I'll take any chance to repost this: https://testing.googleblog.com/2010/07/code-coverage-goal-80-and-no-le… That said, it's very easy to write tests that produce high code coverage, but do not test much that is useful (do they assert the things we truly need to check for?). It's also a pointless exercise to try and cover every single branch (e.g. does every defensive error check need to be asserted on?) It's a delicate balance and I'm sure some people will disagree with this, even.

I would say that Googlers are pretty likely to get locked out of their accounts, it happened all the time when I was there, usually for exceeding rate limits of one kind or another (Googlers get orders of magnitude more emails than anyone else for some reason). Dogfooding is generally practiced at that company. Every major system I worked with had new releases inflicted on insiders first. https://testing.googleblog.com/2014/01/the-google-test-and-development…

This has been encouraged by test frameworks for more than a decade; see e.g. https://testing.googleblog.com/2008/07/tott-expect-vs-assert.html .

Related article (published in 2017): https://testing.googleblog.com/2017/07/code-health-to-comment-or-not-t…

Isn't this considered "Change Detector Test"? Basically what your test does is to ensure there's no change to the result (compare the new serialized output to the old one). Google's ToTT had a good write-up on this topic: https://testing.googleblog.com/2015/01/testing-on-toilet-change-detect…

Single top-priority for software engineering - testing to improve quality. If a lot of organisations are still not writing 100% test coverage to reduce ops and increase reliability with quality then something is broken. It's mostly got to do with engineering culture itself. Google famously did Testing on the toilet experiment which paid off. https://testing.googleblog.com/2007/01/introducing-testing-on-toilet.h…

Yeah, I was misremembering the post from ~8 years ago. I was thinking of this https://testing.googleblog.com/2011/06/testing-at-speed-and-scale-of-g… and it sounds like they do just use Blaze to keep track of explicitly expressed dependencies.

Here's a Google testing blog post about the same thing in 2016. https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-w…

Not a googler, but they posted an update in 2017 with some more information: https://testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-f…

Original blog post (non-wiki version): https://testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-f… Previous discussion: https://news.ycombinator.com/item?id=14146841

Warning: requires logging into google to read post! You can read the original post without the "paywall" here: https://testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-f…

This document is getting absolutely decimated. Why did OP post this without putting in some moderation controls first? Edit: I found the actual engineering blog post that this google docs ended up turning into. It's probably going to be a easier read from here I imagine - https://testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-f…