4 ms·

>But this isn’t obvious, because hundreds of lines of boilerplate obscure this. And when this boilerplate in your own code or someone else's code/framework cha

>But this isn’t obvious, because hundreds of lines of boilerplate obscure this. And when this boilerplate in your own code or someone else's code/framework changes, then what? This is a grossly naive take. We write tests in the first instance to prove that new code works. We then use them to prove that the code under test didn't regress as we make more code changes, framework updates, etc. Later we may change them to demonstrate that destructive modifications still lead to expected outcomes per new requirements. The writer seems only concerned with the former, boiling testing down to moments in time etched into their codebase for eternity. It makes the whole argument rather a straw man.

necovek 3y ago
The author has some great points, and combined with asimpletune's functional approach in a sibling comment, it can work wonders. You probably have never seen purely functional complex code: I don't blame you as many developers haven't (I've seen engineers with 15 years of experience who haven't). It becomes obvious how you can test all the intricacies "just enough". By that I mean that in a function integrating multiple pieces, you test just that those pieces are integrated: no need to test all edgecases of every implementation being used. OTOH, every implementation is independently unit-tested. And in contrast to your claim, that approach really lends itself to constant refactoring that's simple and obvious (solve for the problems in front of you, not for imaginary problems), without leaving stray complicated tests that diminish in value as code gets refactored. The only issue is getting the entire team to switch to this mindset so they don't start breaking the pattern leading to a bigger mess.
- KnobbleMcKnees 3y ago
  I work with purely functional code in my day job and on several side projects, I'm not sure why you'd assume that. 20 years experience as a SE here but honestly I don't think it adds or subtracts from my point, nor should you use it to prop up yours. I think asimplemind's advice is good advice but it is complementary to good and established testing strategy that is in widespread use across paradigms. I treat with deep suspicion the idea that a programming paradigm can subvert the fundamental principles of good testing.
  - necovek 3y ago
    I don't doubt your experience at all: I just extremely rarely see functional approach applied to larger scale projects, and as we mostly work on legacy projects throughout our careers, I find it more likely that people have not seen it than otherwise. TBH, I've seen only two large projects completely following those patterns in my slightly shorter (than yours) 17 years of professional career (on top of a few years of active free software contribution): at my company, I am looking to introduce those patterns for new projects, but none of the existing stuff is doing that. Basically, you get extreme benefits once you follow the pattern fully: smaller codebases are relatively easier to keep that way, but the benefits are not as pronounced either. Anyway, my apologies if you see my previous message as a knock on your experience: I only consider myself lucky to have seen this applied on a complex project integrating many components (external and internal but from other teams) and with heavy development, and I really wish everybody gets to experience it once too :) Again, you possibly did, which is wonderful! It's also ok if that didn't make you as much of a fan as me :)

necovek 3y ago

The author has some great points, and combined with asimpletune's functional approach in a sibling comment, it can work wonders. You probably have never seen purely functional complex code: I don't blame you as many developers haven't (I've seen engineers with 15 years of experience who haven't). It becomes obvious how you can test all the intricacies "just enough". By that I mean that in a function integrating multiple pieces, you test just that those pieces are integrated: no need to test all edgecases of every implementation being used. OTOH, every implementation is independently unit-tested. And in contrast to your claim, that approach really lends itself to constant refactoring that's simple and obvious (solve for the problems in front of you, not for imaginary problems), without leaving stray complicated tests that diminish in value as code gets refactored. The only issue is getting the entire team to switch to this mindset so they don't start breaking the pattern leading to a bigger mess.

KnobbleMcKnees 3y ago
I work with purely functional code in my day job and on several side projects, I'm not sure why you'd assume that. 20 years experience as a SE here but honestly I don't think it adds or subtracts from my point, nor should you use it to prop up yours. I think asimplemind's advice is good advice but it is complementary to good and established testing strategy that is in widespread use across paradigms. I treat with deep suspicion the idea that a programming paradigm can subvert the fundamental principles of good testing.
- necovek 3y ago
  I don't doubt your experience at all: I just extremely rarely see functional approach applied to larger scale projects, and as we mostly work on legacy projects throughout our careers, I find it more likely that people have not seen it than otherwise. TBH, I've seen only two large projects completely following those patterns in my slightly shorter (than yours) 17 years of professional career (on top of a few years of active free software contribution): at my company, I am looking to introduce those patterns for new projects, but none of the existing stuff is doing that. Basically, you get extreme benefits once you follow the pattern fully: smaller codebases are relatively easier to keep that way, but the benefits are not as pronounced either. Anyway, my apologies if you see my previous message as a knock on your experience: I only consider myself lucky to have seen this applied on a complex project integrating many components (external and internal but from other teams) and with heavy development, and I really wish everybody gets to experience it once too :) Again, you possibly did, which is wonderful! It's also ok if that didn't make you as much of a fan as me :)