3 ms·

>> I think no tests makes you slower Bad tests can absolutely make you slower. Good tests can be existential.

Gigachad 4y ago
This might be tied in to the language ecosystem of tooling but after many jobs, I’m yet to see bad tests in ruby. Perhaps there are some CPU cycles wasted on the CI for not so useful tests, but it’s easily paid back by the mountains of useful tests.
- osigurdson 4y ago
  A simple example of a bad test is one enforces an incorrect behaviour (i.e. 1 + 1 == 3). I can't see how a language could improve this situation. Is it possible it is the community as opposed to the language itself?
  - Gigachad 4y ago
    I’m not sure how this really slows you down though. You see the app code is wrong, it breaks a test so you update the test to the new expected result. The benefit is that the tests highlight what changed in the app. So when you update a library and 1+1 changes, it’s an alarm bell to investigate further because you didn’t expect this to happen.
    - osigurdson 4y ago
      This is an example the test/hash antipattern. Here, the tests approach a hash of the source code. When some code changes, the hash no longer matches which fails the test. Great, this is letting us know that something as changed. After examining the changes and decide that they are correct, we update the hash and now the all the tests are green again. Our code base has 100% coverage.
      - abracadabra_ 4y ago
        This is why tests should be seen as an executable specification rather than simply a series of checks. Test_OnePlusOneEqualsTwo() is not as useful as Test_CanAddTwoNumbersTogether() Test for behaviour, not implementation.
- devoutsalsa 4y ago
  Bad tests can include things that timeout due to slow resources, unnecessarily depend on external resources, and stuff like that. It’s a waste of time to debug flaky tests that didn’t ever need to be flaky.
  - Gigachad 4y ago
    Yeah I can see that being a problem. It's always been understood that tests should never reach out to the outside world in the teams I have worked in. And there is a wealth of tooling to mock responses.
- jamie_ca 4y ago
  Longtime rails dev here, the biggest problem I keep running into is testing at inappropriate levels. For example, writing two cucumber (or system) tests to confirm conditional rendering or search filters or some such. These are more appropriate as a view or model test (respectively) and running them naively through the full stack is a huge amount of overhead waste. At an early stage startup with a small app it might not be as big a problem, but where I'm at right now the app is over 10 years old and our test suite with many many parallel workers is still well over an hour cycle time to get that sanity feedback on a commit, and it's painful.

This might be tied in to the language ecosystem of tooling but after many jobs, I’m yet to see bad tests in ruby. Perhaps there are some CPU cycles wasted on the CI for not so useful tests, but it’s easily paid back by the mountains of useful tests.

osigurdson 4y ago
A simple example of a bad test is one enforces an incorrect behaviour (i.e. 1 + 1 == 3). I can't see how a language could improve this situation. Is it possible it is the community as opposed to the language itself?
- Gigachad 4y ago
  I’m not sure how this really slows you down though. You see the app code is wrong, it breaks a test so you update the test to the new expected result. The benefit is that the tests highlight what changed in the app. So when you update a library and 1+1 changes, it’s an alarm bell to investigate further because you didn’t expect this to happen.
  - osigurdson 4y ago
    This is an example the test/hash antipattern. Here, the tests approach a hash of the source code. When some code changes, the hash no longer matches which fails the test. Great, this is letting us know that something as changed. After examining the changes and decide that they are correct, we update the hash and now the all the tests are green again. Our code base has 100% coverage.
    - abracadabra_ 4y ago
      This is why tests should be seen as an executable specification rather than simply a series of checks. Test_OnePlusOneEqualsTwo() is not as useful as Test_CanAddTwoNumbersTogether() Test for behaviour, not implementation.
devoutsalsa 4y ago
Bad tests can include things that timeout due to slow resources, unnecessarily depend on external resources, and stuff like that. It’s a waste of time to debug flaky tests that didn’t ever need to be flaky.
- Gigachad 4y ago
  Yeah I can see that being a problem. It's always been understood that tests should never reach out to the outside world in the teams I have worked in. And there is a wealth of tooling to mock responses.
jamie_ca 4y ago
Longtime rails dev here, the biggest problem I keep running into is testing at inappropriate levels. For example, writing two cucumber (or system) tests to confirm conditional rendering or search filters or some such. These are more appropriate as a view or model test (respectively) and running them naively through the full stack is a huge amount of overhead waste. At an early stage startup with a small app it might not be as big a problem, but where I'm at right now the app is over 10 years old and our test suite with many many parallel workers is still well over an hour cycle time to get that sanity feedback on a commit, and it's painful.