4 ms·

Tests rarely have bugs, I find, so generally dry isn’t critical. Also, dry is for security (see below)

lonelappde 7y ago
Tests have fewer bugs if you write them before the system under test, and if they don't have mocks, and if you have enough of them that anything you get wrong the first time will get noticed by the results of the many similar tests.
- gusmd 7y ago
  > Tests have fewer bugs ... if they don't have mocks 100x this. I've repeatedly fail to convince my team members that mocks are unnecessary in most cases. I've reviewed code with mocks for classes like BigDecimals and built-in arrays. This is especially prevalent in Java teams/codebases. Drives me insane.
smnplk 7y ago
As a preventative measure, I write some tests for my tests. Also in TDD style of course. And on a very rare occasion, I have to write a test for those tests as well.
- natalyarostova 7y ago
  It’s time for TTDD. Start by writing tests for your tests :)
  - afarrell 7y ago
    I do actually do that. I'll write some buggy code in order to learn how to test for it. TDD for me is primarily a way to guide myself toward accomplishing a goal. So I sometimes write way more tests for myself than the business needs. I will then delete the scaffolding tests before I tag my PR for review.
buzzkillington 7y ago
Tests always have bugs, it's just that you don't know about the edge cases yet.
dboreham 7y ago
Tests frequently have bugs, especially bugs that result in the test passing when it should fail.
- chubot 7y ago
  That’s why I make the test fail before writing the code. If the code is already written, then I break it in the minimal way to test the test, and then fix it.
  - sojournerc 7y ago
    IME things never fail in the way you expect them to... You can build a fortification where you think you are weak only to find the enemy is already in the castle.
  - lonelappde 7y ago
    That's a test for your test, so why only run it once transiently instead of running every time? "Mutant" testing helps with this. It's basically fuzzing your test code to make sure that every line is meaningful.
    - chubot 7y ago
      I can see how that would be useful, but I also think it's a matter of priorities. I'm basically saying I rarely have bugs in my tests because I verify them first. In fact I can't think of a single bug in my tests over the last 4 years (or even 10 years), but I can think of dozens of bugs in my code. For example here are some pretty exhaustive tests I've written for shell, which have exposed dozens of bugs in bash and other shells (and my own shell Oil): https://www.oilshell.org/release/0.7.pre11/test/spec.wwz/osh.html https://www.oilshell.org/release/0.7.pre11/test/spec.wwz/osh... I would rather spend time using the tests to improve the code than improving the tests themselves. But I don't doubt that technique could be useful for some projects (likely very old and mature ones)
      - scaryclam 7y ago
dragonwriter 7y ago
> Tests rarely have bugs, I find, so generally dry isn’t critical DRY is important for tests, but the areas where it is have probably (if you aren't writing a testing framework or using a language that doesn't have one that covers your use case) largely covered by your testing framework already.
jammygit 7y ago
Tests are there to catch issues. In a way, almost every bug that makes it to production is a test bug. Not to mention the inconsistent tests that fail so randomly from timing issues that the team ignores them

Tests have fewer bugs if you write them before the system under test, and if they don't have mocks, and if you have enough of them that anything you get wrong the first time will get noticed by the results of the many similar tests.

gusmd 7y ago
> Tests have fewer bugs ... if they don't have mocks 100x this. I've repeatedly fail to convince my team members that mocks are unnecessary in most cases. I've reviewed code with mocks for classes like BigDecimals and built-in arrays. This is especially prevalent in Java teams/codebases. Drives me insane.

smnplk 7y ago

As a preventative measure, I write some tests for my tests. Also in TDD style of course. And on a very rare occasion, I have to write a test for those tests as well.

natalyarostova 7y ago
It’s time for TTDD. Start by writing tests for your tests :)
- afarrell 7y ago
  I do actually do that. I'll write some buggy code in order to learn how to test for it. TDD for me is primarily a way to guide myself toward accomplishing a goal. So I sometimes write way more tests for myself than the business needs. I will then delete the scaffolding tests before I tag my PR for review.

buzzkillington 7y ago

Tests always have bugs, it's just that you don't know about the edge cases yet.

dboreham 7y ago

Tests frequently have bugs, especially bugs that result in the test passing when it should fail.

chubot 7y ago
That’s why I make the test fail before writing the code. If the code is already written, then I break it in the minimal way to test the test, and then fix it.
- sojournerc 7y ago
  IME things never fail in the way you expect them to... You can build a fortification where you think you are weak only to find the enemy is already in the castle.
- lonelappde 7y ago
  That's a test for your test, so why only run it once transiently instead of running every time? "Mutant" testing helps with this. It's basically fuzzing your test code to make sure that every line is meaningful.
  - chubot 7y ago
    I can see how that would be useful, but I also think it's a matter of priorities. I'm basically saying I rarely have bugs in my tests because I verify them first. In fact I can't think of a single bug in my tests over the last 4 years (or even 10 years), but I can think of dozens of bugs in my code. For example here are some pretty exhaustive tests I've written for shell, which have exposed dozens of bugs in bash and other shells (and my own shell Oil): https://www.oilshell.org/release/0.7.pre11/test/spec.wwz/osh.html https://www.oilshell.org/release/0.7.pre11/test/spec.wwz/osh... I would rather spend time using the tests to improve the code than improving the tests themselves. But I don't doubt that technique could be useful for some projects (likely very old and mature ones)
    - scaryclam 7y ago

dragonwriter 7y ago

> Tests rarely have bugs, I find, so generally dry isn’t critical DRY is important for tests, but the areas where it is have probably (if you aren't writing a testing framework or using a language that doesn't have one that covers your use case) largely covered by your testing framework already.

jammygit 7y ago

Tests are there to catch issues. In a way, almost every bug that makes it to production is a test bug. Not to mention the inconsistent tests that fail so randomly from timing issues that the team ignores them