Hacker News Reader

Comment by arcticbull | Hacker News Reader

I suppose we're referring to different kinds of testing. Manual QA, etc, on prod sure.

But if you're building client software artifacts, to unit test or integration test involves building different software in a different configuration, with different software and running it in a test harness. To facilitate unit testing or integration testing client software you:

- Build with a lower optimization level (-O0 usually) so that the generated code bares even a passing resemblance to what you actually wrote and your debugger can follow along.

- Generate debug info.

- Avoid stripping symbols.

- Enable logging.

- Build and link your tests code into a library artifact.

- Run it in a test harness.

That's not testing what you ship. It's testing something pretty close, obviously, but does not bear any semblance to a deterministic build.

View on HN

On the contrary; it's quite possible to design automated tests that operate on release artifacts. This is true not only at the integration level (testing the external interfaces of the artifact in a black-box manner), but also at a more granular level; e.g., running lower-level unit tests in your code's dependency structure.

It's true that not all tests which are possible to run in debug configuration can also be run on a release artifact; e.g. if there are test-only interfaces that are compiled out in the release configuration.

I think maybe the source of the confusion in this conversation is perhaps the kind of artifact being tested? For example, if I were developing ffmpeg, to choose an arbitrary example, I would absolutely have tests which operate on the production artifact -- the binary compiled in release mode -- which only exercise public interfaces of the tool; e.g. a test which transcodes file A to file B and asserts correctness in some way. This kind of test should be absolutely achievable both in dev builds as well as when testing the deliverable artifact.

No, I'm saying you re-run your automated unit tests on the release build because there's no reason not to.

If you have test failures in opt/stripped mode, they're more annoying to debug yes, but wouldn't you want to know?

Another way of putting this is that when you

> - Build and link your tests code into a library artifact.

You build and link the same object files that will be built into the release binary artifact, deterministically.

> - Enable logging.

I, uhh, usually do this in my released software too.

> I, uhh, usually do this in my released software too.

Do you have any idea how annoying it is to get logged garbage when starting something on the command line (looking at you IntelliJ)?

I once spent several weeks hunting through Hadoop stack traces for a null pointer exception that was being thrown in a log function. If the logging wasn’t being done in production, I wouldn’t have wasted my life and could have been doing useful things. Sadly, shutting down the cluster to patch it wasn’t an option, so I had to work around it by calling something unrelated to ensure the variable wasn’t null when it did log.

Yes, which is why I regularly (think quarterly or annually) check to make sure we have good log hygiene, and are logging at appropriate log levels and not logging useless information.

I have alerting set up to page me if the things I care about start logging more than the occasional item at ERROR, so I have to pay some attention or I get pestered.

That's called a debug build.

Not a test.

Reply on news.ycombinator.com