7 ms·

> Only tests for the testing sake. Bazillion unit tests which not really ensure that your application does what it should This is what happens when tests and c

> Only tests for the testing sake. Bazillion unit tests which not really ensure that your application does what it should This is what happens when tests and code coverage are mandated. Yes, testing does work, and is an important part of any large-scale project. The key is to recognize and implement a few different kinds of testing: 1) Unit tests, to help with the development process, and run any part of the code quickly, without any external dependencies, and test for correctness. 2) Performance tests - performance is a feature, and it's important to recognize regressions or improvements. 3) Integration tests, to see if the software actually works with its external dependencies. 4) Post-release checkouts and monitoring - after releasing the software, a method to check that the release itself was successful (as opposed to the software), before any live users are exposed to it. These are all important, and while there may be some overlap, often people don't see distinction and try to make do with just one kind, and argue that the other kinds are "wrong", which is counterproductive.

l1am0 4y ago
> 4) Post-release checkouts and monitoring How did you ensure that in the past? Sounds to me like it would not really be possible to do this before live users are exposed to the system
- toast0 4y ago
  How effectively you can do this depends on how you direct traffic. But I'd do it by having the new version running on production servers where traffic is directed elsewhere. Or, sometimes you can do something similar with feature flags --- push the code everywhere, but only turn on the feature flags for test users at first. Doesn't help if your feature flag or other traffic direction is broken, of course. Also, if you use the same packaging for 'staging' and 'production', staging tests your packaging.

l1am0 4y ago

> 4) Post-release checkouts and monitoring How did you ensure that in the past? Sounds to me like it would not really be possible to do this before live users are exposed to the system

toast0 4y ago
How effectively you can do this depends on how you direct traffic. But I'd do it by having the new version running on production servers where traffic is directed elsewhere. Or, sometimes you can do something similar with feature flags --- push the code everywhere, but only turn on the feature flags for test users at first. Doesn't help if your feature flag or other traffic direction is broken, of course. Also, if you use the same packaging for 'staging' and 'production', staging tests your packaging.