5 ms·

Oh absolutely, keeping things simple should never be restricted to just production code. Testing code should be simple too. The idea that tests inhibits refact

by beny23 6y ago

Oh absolutely, keeping things simple should never be restricted to just production code. Testing code should be simple too. The idea that tests inhibits refactoring I find problematic though. Good tests enable refactoring. If the tests are too complex for anyone to change the code, the the code is too complex. Any complex system should be composed of simple components. Now this applies to monoliths as well as microservices. I agree it is easy to fall into the trap of thinking that tests are boring though as devs become more experienced there should be less of that thinking, hopefully.

CraigJPerry 6y ago
>> If the tests are too complex for anyone to change the code, the the code is too complex In enterprise software, the pattern i see is specifically coupling rather than garden variety complexity. There’s a really pervasive idea that unit testing means 1:1 mapping of test class to production code class. To put it another way, there’s this really common but terrible idea that tests should map to your current implementation rather than the behaviour you want. Worse, some check in test cases that should only exist locally during development, they do things like directly test private implementations. A related issue is no one ever deletes tests. Testing done well, is utterly transformational. I took a piece of enterprise software, it wasn’t badly written per se but it was hard to release. 80%+ of releases were rolled back due to issues found in production. For each release, 1 of 7 “experts” were required to review your change to this component (to make it worse it changed fairly frequently). The problem was only 2 of those 7 had a track record of only approving good changes. I’m ashamed to say i was one of the other 5 - i reviewed and approved a couple of changes that had to be rolled back from prod. So, i thought sod this and i grabbed the stingy nettles. The code was not written to be testable but fast forward 16,000 (i had a small team) test cases which execute in around 16 minutes and over the past years that software continues to be released as frequently but has NEVER had a prod rollback since. The 7 experts idea is disbanded, it’s just a normal pull request these days. Lead time on changes is about 1/3 what it was - all the faffing about exploring model output in excel for hours if not days is gone, it’s just all captured as tests. It wasn’t cheap to do this but back of the envelope calculations, it repaid within 3 months just on lack of prod outages.
- travisjungroth 6y ago
  > A related issue is no one ever deletes tests. I think this is a huge problem. I’m not sure why it exists. “If we have more tests it will be harder to change the code.” is an argument people make sincerely. Then... just delete the tests. If your argument against having these tests is you can imagine a point where they become a burden, just keep in mind that it’s really, really fast to delete code. “Untested” is a state we can get back to at any moment. Maybe the tests will provide a lot of value until then. Maybe if we do a big refactor we’ll delete the old tests that are too low level and make new ones. That’s fine.
  - hinkley 6y ago
    I joke that we should make the team watch one of those Hoarder TV shows, but it's a Tears of a Clown sort of situation. Try telling people that you're deleting a flaky test and they'll stop working on their current story to try to stop you. It's as predictable as the phases of the moon.
- hinkley 6y ago
  > To put it another way, there’s this really common but terrible idea that tests should map to your current implementation rather than the behaviour you want. I think if you were prioritizing, then the most bang for the buck comes from making your white box tests as stupid-simple as you possibly can. Since those demand a particular implementation.
DarkWiiPlayer 6y ago
> If the tests are too complex for anyone to change the code, the the code is too complex. No, more than that, it's a sign that the tests are not just testing for how code behaves, but also its implementation details. With well-written tests, you can completely re-structure some code and, if it still does the same thing, the tests for that code will still pass. If the code being changed has several components with their own tests, then either those components have no interface change, in which case the previous paragraph applies to them, or the do, in which case their tests should be easy to adapt.
hinkley 6y ago
> Good tests enable refactoring. I don't disagree. So when I do find tests that inhibit refactoring, what do you suppose I infer about those tests?

by beny23 6y ago

CraigJPerry 6y ago

>> If the tests are too complex for anyone to change the code, the the code is too complex In enterprise software, the pattern i see is specifically coupling rather than garden variety complexity. There’s a really pervasive idea that unit testing means 1:1 mapping of test class to production code class. To put it another way, there’s this really common but terrible idea that tests should map to your current implementation rather than the behaviour you want. Worse, some check in test cases that should only exist locally during development, they do things like directly test private implementations. A related issue is no one ever deletes tests. Testing done well, is utterly transformational. I took a piece of enterprise software, it wasn’t badly written per se but it was hard to release. 80%+ of releases were rolled back due to issues found in production. For each release, 1 of 7 “experts” were required to review your change to this component (to make it worse it changed fairly frequently). The problem was only 2 of those 7 had a track record of only approving good changes. I’m ashamed to say i was one of the other 5 - i reviewed and approved a couple of changes that had to be rolled back from prod. So, i thought sod this and i grabbed the stingy nettles. The code was not written to be testable but fast forward 16,000 (i had a small team) test cases which execute in around 16 minutes and over the past years that software continues to be released as frequently but has NEVER had a prod rollback since. The 7 experts idea is disbanded, it’s just a normal pull request these days. Lead time on changes is about 1/3 what it was - all the faffing about exploring model output in excel for hours if not days is gone, it’s just all captured as tests. It wasn’t cheap to do this but back of the envelope calculations, it repaid within 3 months just on lack of prod outages.

travisjungroth 6y ago
> A related issue is no one ever deletes tests. I think this is a huge problem. I’m not sure why it exists. “If we have more tests it will be harder to change the code.” is an argument people make sincerely. Then... just delete the tests. If your argument against having these tests is you can imagine a point where they become a burden, just keep in mind that it’s really, really fast to delete code. “Untested” is a state we can get back to at any moment. Maybe the tests will provide a lot of value until then. Maybe if we do a big refactor we’ll delete the old tests that are too low level and make new ones. That’s fine.
- hinkley 6y ago
  I joke that we should make the team watch one of those Hoarder TV shows, but it's a Tears of a Clown sort of situation. Try telling people that you're deleting a flaky test and they'll stop working on their current story to try to stop you. It's as predictable as the phases of the moon.
hinkley 6y ago
> To put it another way, there’s this really common but terrible idea that tests should map to your current implementation rather than the behaviour you want. I think if you were prioritizing, then the most bang for the buck comes from making your white box tests as stupid-simple as you possibly can. Since those demand a particular implementation.

DarkWiiPlayer 6y ago

> If the tests are too complex for anyone to change the code, the the code is too complex. No, more than that, it's a sign that the tests are not just testing for how code behaves, but also its implementation details. With well-written tests, you can completely re-structure some code and, if it still does the same thing, the tests for that code will still pass. If the code being changed has several components with their own tests, then either those components have no interface change, in which case the previous paragraph applies to them, or the do, in which case their tests should be easy to adapt.

hinkley 6y ago

> Good tests enable refactoring. I don't disagree. So when I do find tests that inhibit refactoring, what do you suppose I infer about those tests?