5 ms·

One of the areas where I really like "incidental duplication" is in tests. Tests can sometimes be very repetitive and identical, and it's tempting to want to r

One of the areas where I really like "incidental duplication" is in tests. Tests can sometimes be very repetitive and identical, and it's tempting to want to refactor it in some clever way. That's almost never good. On top of the reasons laid out in parent comment, tests also function as unofficial documentation. I like having everything explicit in there, it makes them easier to read and understand.

lonelappde 7y ago
Terrible acronym for a good idea: DAMP stackoverflow.com/questions/6453235/what-does-damp-not-dry-mean-when-talking-about-unit-tests
blazespin 7y ago
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
ummonk 7y ago
If you try to abstract away tests, you often just end up re-implementing the same abstractions used in the actual code, and you can end up not catching unfounded assumptions that your abstraction is making in both the tests and the code. There is a scope for having test helpers / utils to make tests easier to write, but you should be minimalist with these.
- 3pt14159 7y ago
  I agree, but some test helpers are reasonable. It's about balance and readability of the tests in question. Otherwise integration tests end up being a hundred lines of code.
- rbanffy 7y ago
  Tests should also be treated as a form of documentation. A test should reflect the way you'd use the code in real life as closely as feasible.
- ajuc 7y ago
  The problem with abstractions in testing is - you should test it :)
philwelch 7y ago
I do think a lot of test frameworks would do well to support data-driven testing a la Spock: http://spockframework.org/spock/docs/1.0/data_driven_testing.html http://spockframework.org/spock/docs/1.0/data_driven_testing...
therealdrag0 7y ago
I'm not sure I agree. I like to move all setup code to helper methods so that my tests are just a few lines // Given <setup> // When <thing happens> // Expect <thing> to be <such> This allows the reader to easily see which workflows are actually tested. If the reader is interested in implementations the utility code is one click away and usually only needs to be looked at once to be completely understood. The test bodies themselves however have many flavors for many work-flows so getting rid of the repetition is critical to highlight the specific nature of individual tests.

lonelappde 7y ago

Terrible acronym for a good idea: DAMP stackoverflow.com/questions/6453235/what-does-damp-not-dry-mean-when-talking-about-unit-tests

blazespin 7y ago

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

ummonk 7y ago

If you try to abstract away tests, you often just end up re-implementing the same abstractions used in the actual code, and you can end up not catching unfounded assumptions that your abstraction is making in both the tests and the code. There is a scope for having test helpers / utils to make tests easier to write, but you should be minimalist with these.

3pt14159 7y ago
I agree, but some test helpers are reasonable. It's about balance and readability of the tests in question. Otherwise integration tests end up being a hundred lines of code.
rbanffy 7y ago
Tests should also be treated as a form of documentation. A test should reflect the way you'd use the code in real life as closely as feasible.
ajuc 7y ago
The problem with abstractions in testing is - you should test it :)

philwelch 7y ago

I do think a lot of test frameworks would do well to support data-driven testing a la Spock: http://spockframework.org/spock/docs/1.0/data_driven_testing.html http://spockframework.org/spock/docs/1.0/data_driven_testing...

therealdrag0 7y ago

I'm not sure I agree. I like to move all setup code to helper methods so that my tests are just a few lines // Given <setup> // When <thing happens> // Expect <thing> to be <such> This allows the reader to easily see which workflows are actually tested. If the reader is interested in implementations the utility code is one click away and usually only needs to be looked at once to be completely understood. The test bodies themselves however have many flavors for many work-flows so getting rid of the repetition is critical to highlight the specific nature of individual tests.