Hacker News Reader

I wouldn't call your second case unit testing, but rather integration testing.

Part of the point of unit testing is that you keep the 'unit' under test to be as small as possible so you don't have these sorts of problems and can run tests as frequently as is useful. It doesn't remove the need for other types of testing suites, but they can be isolated and run at separate times.

View on HN

I think the real point is that "testing in production," more commonly known as "monitoring," has to happen anyway. So early on, if you have a choice between adding better, more complete monitoring and adding tests, even integration ones, the monitoring will prove more helpful once you deploy than the tests were. Don't get me wrong, it sucks having to manually perform integration tests but when a product resembles a website and is semi-automatically deployed (e.g. has staging servers with automatic deployment, rapid rollback deploys or a canary-server deployment model, a few minutes of caching and few to no expectations that the app operates perfectly as long as it can be fixed within half a day, well, that's a very different project. In that environment, the piece of mind monitoring provides (no client errors in production) largely outweighs having no monitoring, just tests (did I test everything? What about (obscure government agency) using (outdated version of IE) who is reporting that bug?). Of course, as code is more complex than a website, or where you begin to have significant JavaScript, having at minimum tests for success-paths will help prevent regressions for application-wide changes, e.g. adding PJAX to a site and missing an onload. It's just harder to justify tests until you really need them on some assignments.

Reply on news.ycombinator.com