If your production code is factored out into its own target, you can use assert_no_deps() to accomplish this, sort of, but this is a top-down assertion, rather than the bottom-up assertion that testonly is (where the top == the roots of the graph, like binaries).

I understand the intent, but this seems like a dodgy proposition because it would mean that you could never write a test for that code.

Also, at least the way testonly propagates in my understanding, it would mean that you could not have an integration test that depended on the actual chrome binaries.

I also fail to see how preventing a target from being included in test could still allow that target's code being tested. And I don't think there should be any untested code.

I understand why we don't want to declare a piece of code forever untestable. At the very least, it should be included in system tests. However, there are pieces of code that clearly shouldn't be used in unit tests.

When using external services, there always a layer of code that cannot be part of a unit test, because it would actually contact that service. I recently discovered tests that did not realize they were reaching real backends and sharing side effects between runs.

Perhaps it is possible to adjust the question:

Is there a way to prevent someone from reaching that innermost layer of code, unless they explicitly say it's what they want?

So actually the assert_no_deps (described in [1]) suggested by dpranke@ might be the right tool here. It would allow you to forbid depending on the real backend in the unit_tests target. The tricky part would be placing the tests which actually need to depend on this target. It would likely need to be a special test target and the bots would need to know to run it.

[1] https://chromium.googlesource.com/chromium/src/+/master/tools/gn/docs/reference.md

vabr going hobby only -> reducing involvement.
Please contact me directly in urgent matters.