6 ms·

So it's a fair point that the fidelity of non-prod environments are inherently limited and you still need a bunch of other stuff like canaries, automated canary

So it's a fair point that the fidelity of non-prod environments are inherently limited and you still need a bunch of other stuff like canaries, automated canary analysis, automated rollbacks, zone fault-tolerance, feature-flags, chaos engineering, server and client-side instrumentation, but this is generally 'next-level' stuff when most shops aren't even getting the basics right. For the overwhelming majority of non-prod environments and release processes I've seen they usually have basic problems and would catch a lot more issues with additional engineering investment. I.e Releases aren't automated, self-contained, or idempotent. Unit testing coverage is bad, integration tests are non-existent, data used isn't reflective of reality, there is no performance or load testing done, downstream or upstream systems have poorly defined interfaces and are excessively mocked or just not considered.

smoe 6y ago
Agreed I like the view i picked up somewhere but don't remember from whom: Tests are not there to prove something is working, but to prove something is not working. They are a fairly cheap way to tell me during development that this ain't going to work no matter what. And if everything compiles and the tests and reviews pass, I think this has a good shot at working out in production, but there still might well be cases and circumstances I haven't or coulnd't have considered. No setup will cover 100%, but with not that much work you can already get quite far. The tricky thing in my opinions is more on deciding which kind of tests, processes and automations are actually worth implementing and maintaining at a given stage of a project.
- table-delete 6y ago
  Glenford Myers in "The Art of Software Testing" said: "Testing is the process of executing a program with the intent of finding errors." The preface to this is even more enlightening: "When you test a program, you want to add some value to it. Adding value through testing means raising the quality or reliability of the program. Raising the reliability of the program means finding and removing errors. Therefore, don’t test a program to show that it works; rather, you should start with the assumption that the program contains errors (a valid assumption for almost any program) and then test the program to find as many of the errors as possible."
  - faizshah 6y ago
    I like this quote from Kent Beck: “ It is impossible to test absolutely everything, without the tests being as complicated and error-prone as the code. It is suicide to test nothing (in this sense of isolated, automatic tests). So, of all the things you can imagine testing, what should you test? You should test things that might break. If code is so simple that it can't possibly break, and you measure that the code in question doesn't actually break in practice, then you shouldn't write a test for it... Testing is a bet. The bet pays off when your expectations are violated [when a test that you expect to pass fails, or when a test that you expect to fail passes]... So, if you could, you would only write those tests that pay off. Since you can't know which tests would pay off (if you did, then you would already know and you wouldn't be learning anything), you write tests that might pay off. As you test, you reflect on which kinds of tests tend to pay off and which don't, and you write more of the ones that do pay off, and fewer of the ones that don't.” Source: https://softwareengineering.stackexchange.com/a/244709 https://softwareengineering.stackexchange.com/a/244709
    - josephg 6y ago
      When I’ve gone full TDD on projects, I’m always surprised to find there’s a power law distribution or something on failing tests. Most of the tests I write never catch a bug in the life of the software. Something like 90% of the value of a test suite could be achieved with only about 10% of the tests. Of course, the trick is figuring out which tests are going to repeatedly fail ahead of time. But there’s something interesting down this rabbit hole. I wonder if it would be worth collecting per-test stats through the life of a project to explore this.
      - lmm 6y ago
        You'd get a lot of the value by just being willing to delete tests once it's clear they're not serving any purpose. Sadly a lot of people would rather see a high test coverage percentage than have an effective test suite.
        nitrogen 6y ago
faizshah 6y ago
Wholeheartedly agree to everything you’ve said. I have worked at a lot of places where automated testing is almost non existent. Instead they use staging/testing environments and manual testing. For all these projects they frequently have downtime or errors in prod where something was uncaught. It takes ages to release a fix because they have to carefully research how a change affects other code instead of running a test suite. They are convinced that unit tests are unnecessary extra work for their project but they don’t realize they are losing time by having to manually test and research changes. I think a lot of the focus on fancy testing practices has lead some programmers to think testing is a load of extra work when things will fail in prod anyway. We need to push back and say automated tests are a way to codify assumptions about the code and help speed up the prototype-build-test-release loop. Side-note: self documenting code is a myth but I digress.
- anon9001 6y ago
  > They are convinced that unit tests are unnecessary extra work for their project but they don’t realize they are losing time by having to manually test and research changes. If people are finding tests unnecessary extra work, maybe they're right for their project. Most jobs are just "ship feature asap, try not to break anything, repeat". Most managers don't care about code quality as much as speed of delivery. Most coders don't have much "skin in the game" and can always get another job when the project fails. Writing tests is a sign that you know what you're building, you have a methodology for building it, and you have a commitment to keeping it working in the future. That's simply not the requirements for most programming work, and it can be a disservice to both the coders and the management to push for testing that won't help achieve the business goals. If a business needs to iterate fast and reliably, write tests. If a business needs to iterate fast and is ok with breaking things, skip the tests and have a rollback plan instead.
  - faizshah 6y ago
    Sorry, I have to completely disagree with this. This is a horrible, but often used, excuse. In my experience these coders are doing exactly what you would do in a unit test but instead they are doing it manually by adding printlns and testing various values on the command line, in a repl, a notebook, or a main. Instead of manually adding these things every time you want to test your work, if you just added some basic unit tests it would speed up your delivery. Not only that but you can't "forget to test that" because you're forced to write down the test cases instead of deleting them when you're done. If you add up all the time you spent adding printlns to your code, testing various input values in a main method, researching inside your codebase to see what could fail, debugging your ETL because you forgot about an uncaught error or a different kind of null in this column that only came up after it processed 3TB of data (real example), etc. I guarantee you would save time if you just implement some basic automated tests instead of testing in prod or staging.

smoe 6y ago

Agreed I like the view i picked up somewhere but don't remember from whom: Tests are not there to prove something is working, but to prove something is not working. They are a fairly cheap way to tell me during development that this ain't going to work no matter what. And if everything compiles and the tests and reviews pass, I think this has a good shot at working out in production, but there still might well be cases and circumstances I haven't or coulnd't have considered. No setup will cover 100%, but with not that much work you can already get quite far. The tricky thing in my opinions is more on deciding which kind of tests, processes and automations are actually worth implementing and maintaining at a given stage of a project.

table-delete 6y ago
Glenford Myers in "The Art of Software Testing" said: "Testing is the process of executing a program with the intent of finding errors." The preface to this is even more enlightening: "When you test a program, you want to add some value to it. Adding value through testing means raising the quality or reliability of the program. Raising the reliability of the program means finding and removing errors. Therefore, don’t test a program to show that it works; rather, you should start with the assumption that the program contains errors (a valid assumption for almost any program) and then test the program to find as many of the errors as possible."
- faizshah 6y ago
  I like this quote from Kent Beck: “ It is impossible to test absolutely everything, without the tests being as complicated and error-prone as the code. It is suicide to test nothing (in this sense of isolated, automatic tests). So, of all the things you can imagine testing, what should you test? You should test things that might break. If code is so simple that it can't possibly break, and you measure that the code in question doesn't actually break in practice, then you shouldn't write a test for it... Testing is a bet. The bet pays off when your expectations are violated [when a test that you expect to pass fails, or when a test that you expect to fail passes]... So, if you could, you would only write those tests that pay off. Since you can't know which tests would pay off (if you did, then you would already know and you wouldn't be learning anything), you write tests that might pay off. As you test, you reflect on which kinds of tests tend to pay off and which don't, and you write more of the ones that do pay off, and fewer of the ones that don't.” Source: https://softwareengineering.stackexchange.com/a/244709 https://softwareengineering.stackexchange.com/a/244709
  - josephg 6y ago
    When I’ve gone full TDD on projects, I’m always surprised to find there’s a power law distribution or something on failing tests. Most of the tests I write never catch a bug in the life of the software. Something like 90% of the value of a test suite could be achieved with only about 10% of the tests. Of course, the trick is figuring out which tests are going to repeatedly fail ahead of time. But there’s something interesting down this rabbit hole. I wonder if it would be worth collecting per-test stats through the life of a project to explore this.
    - lmm 6y ago
      You'd get a lot of the value by just being willing to delete tests once it's clear they're not serving any purpose. Sadly a lot of people would rather see a high test coverage percentage than have an effective test suite.
      - nitrogen 6y ago

faizshah 6y ago

Wholeheartedly agree to everything you’ve said. I have worked at a lot of places where automated testing is almost non existent. Instead they use staging/testing environments and manual testing. For all these projects they frequently have downtime or errors in prod where something was uncaught. It takes ages to release a fix because they have to carefully research how a change affects other code instead of running a test suite. They are convinced that unit tests are unnecessary extra work for their project but they don’t realize they are losing time by having to manually test and research changes. I think a lot of the focus on fancy testing practices has lead some programmers to think testing is a load of extra work when things will fail in prod anyway. We need to push back and say automated tests are a way to codify assumptions about the code and help speed up the prototype-build-test-release loop. Side-note: self documenting code is a myth but I digress.

anon9001 6y ago
> They are convinced that unit tests are unnecessary extra work for their project but they don’t realize they are losing time by having to manually test and research changes. If people are finding tests unnecessary extra work, maybe they're right for their project. Most jobs are just "ship feature asap, try not to break anything, repeat". Most managers don't care about code quality as much as speed of delivery. Most coders don't have much "skin in the game" and can always get another job when the project fails. Writing tests is a sign that you know what you're building, you have a methodology for building it, and you have a commitment to keeping it working in the future. That's simply not the requirements for most programming work, and it can be a disservice to both the coders and the management to push for testing that won't help achieve the business goals. If a business needs to iterate fast and reliably, write tests. If a business needs to iterate fast and is ok with breaking things, skip the tests and have a rollback plan instead.
- faizshah 6y ago
  Sorry, I have to completely disagree with this. This is a horrible, but often used, excuse. In my experience these coders are doing exactly what you would do in a unit test but instead they are doing it manually by adding printlns and testing various values on the command line, in a repl, a notebook, or a main. Instead of manually adding these things every time you want to test your work, if you just added some basic unit tests it would speed up your delivery. Not only that but you can't "forget to test that" because you're forced to write down the test cases instead of deleting them when you're done. If you add up all the time you spent adding printlns to your code, testing various input values in a main method, researching inside your codebase to see what could fail, debugging your ETL because you forgot about an uncaught error or a different kind of null in this column that only came up after it processed 3TB of data (real example), etc. I guarantee you would save time if you just implement some basic automated tests instead of testing in prod or staging.