3 ms·

I like it. I appreciate someone writing into the void how this helps them focus and be productive in their workflow. Who cares whether it 'fits the technical s

by thadt 4y ago

I like it. I appreciate someone writing into the void how this helps them focus and be productive in their workflow. Who cares whether it 'fits the technical semantic definition of INSERT_ACRONYM_HERE'. Unit tests are a literal investment - somewhat like buying insurance. Sometimes they're really great - almost necessary - and other times they're not worth the price. The article is offering a point of view of how tests are paying for themselves in an indirect way, which is useful to think about in the cost benefit equation. The position of "insurance is useless" means maybe you just haven't been in a situation where it could really, really save your bacon. Likewise, if your rule of thumb is "buy all the insurance, all the time" - then BestBuy will gladly sell you a $5 'product protection plan' on your $10 purchase.

matthewfcarlson 4y ago
Yes, you're getting it exactly. This was for a personal project. The expected audience for it was my spouse and I and writing tests seemed like a nuisance. I don't even know why I started as getting the environment building in a testing harness was actually quite a bit of work. I noticed a benefit I didn't expect and wanted to share. Did I not have a concrete idea of what TDD was when I wrote it? Yes. I had muddled test first development with test driven development as the two people I knew who were big on TDD were focused on TFD as they were refactoring large legacy codebases. I'm still murky on what TDD is (and it sounds like opinions differ) but I don't think I've discovered anything new. Just new to me.
- Jtsummers 4y ago
  Even if you don't want to read Beck's book on it, TDD is ludicrously simple and still somehow greatly misunderstood: 1. Write a test 2. See that it fails (if it passes, you're testing a feature you already implemented or you're testing something you don't mean to be testing) 3. Make it pass (by changing the code, not the test, seen that too many times) 4. Refactor 5. Repeat The catchphrase is "red-green-refactor". I don't know why people try and make it more complicated than that. Regarding your post, just wanted to say that if you took my other comments as criticism of you they were not. Your misunderstanding of TDD is actually very common and I was intending to address that, specifically. I actual consider the fact that you both rejected the flawed TFD-style (and mass creation of tests that comes with it) and rediscovered TDD (the above process, more or less) both amusing and a positive thing. It shows you're doing what many others aren't, actually thinking and experimenting to discover techniques that work (at least for you and on this project).
  - Groxx 4y ago
    >I don't know why people try and make it more complicated than that. Given that the author of the term wrote a whole book about it rather than just tweeting those steps, I think over-complicating may be part of its genetics. Others are just continuing the trend. --- For the record: yeah, short-cycle red/green/refactor fits how I like to do TDD. I don't know that I'd claim that it is TDD though - by far the majority I've run across take it to extremes, though of course my coding-exposure circle is skewed and may not even remotely be representative. In that way, TDD sits in a very similar brain-space for me as Scrum does. Useful foundations, utter nonsense if taken to extremes, unsure if a net-positive influence (globally, not personally) in the end. I have seen a looooot of negative-value tests, in ever-increasing quantity as time goes on, in the name of TDD.
    - Jtsummers 4y ago
      As a partial defense for the length of the book, it was "Test-Driven Development by Example". Hard to fit examples into the page or two needed to explain the core concept itself. Letting ideas like this move into the "similar brain-space ... as Scrum" is dangerous. You're actively choosing not to think at that point, you're choosing anti-thought over thought. Move too many things into that brain-space and you're going to become thoughtless. Don't let that happen, you have more to contribute to the world than becoming another mindless automaton. Engage with the idea instead, understand why it does or does not make sense to you. Why it is or is not applicable to some area. Why other people have different ideas about it or disagree on its applicability. You'll be much better for it. And as much as I also dislike Scrum, it's worth engaging with its core ideas as well.
      - Groxx 4y ago
        I think you may be reading too much into my Scrum brain-space. Or maybe projecting? I've looked at those things. Found what I think are the core valuable bits, and how they apply to me and my situation. And I do not want to interact with them in a professional setting, because they are almost always distorted beyond any reasonable interpretation of their core, losing all meaning of the term and being used as an excuse to continue bad behaviors. They're quite similar in that respect.

by thadt 4y ago

matthewfcarlson 4y ago

Yes, you're getting it exactly. This was for a personal project. The expected audience for it was my spouse and I and writing tests seemed like a nuisance. I don't even know why I started as getting the environment building in a testing harness was actually quite a bit of work. I noticed a benefit I didn't expect and wanted to share. Did I not have a concrete idea of what TDD was when I wrote it? Yes. I had muddled test first development with test driven development as the two people I knew who were big on TDD were focused on TFD as they were refactoring large legacy codebases. I'm still murky on what TDD is (and it sounds like opinions differ) but I don't think I've discovered anything new. Just new to me.

Jtsummers 4y ago
Even if you don't want to read Beck's book on it, TDD is ludicrously simple and still somehow greatly misunderstood: 1. Write a test 2. See that it fails (if it passes, you're testing a feature you already implemented or you're testing something you don't mean to be testing) 3. Make it pass (by changing the code, not the test, seen that too many times) 4. Refactor 5. Repeat The catchphrase is "red-green-refactor". I don't know why people try and make it more complicated than that. Regarding your post, just wanted to say that if you took my other comments as criticism of you they were not. Your misunderstanding of TDD is actually very common and I was intending to address that, specifically. I actual consider the fact that you both rejected the flawed TFD-style (and mass creation of tests that comes with it) and rediscovered TDD (the above process, more or less) both amusing and a positive thing. It shows you're doing what many others aren't, actually thinking and experimenting to discover techniques that work (at least for you and on this project).
- Groxx 4y ago
  >I don't know why people try and make it more complicated than that. Given that the author of the term wrote a whole book about it rather than just tweeting those steps, I think over-complicating may be part of its genetics. Others are just continuing the trend. --- For the record: yeah, short-cycle red/green/refactor fits how I like to do TDD. I don't know that I'd claim that it is TDD though - by far the majority I've run across take it to extremes, though of course my coding-exposure circle is skewed and may not even remotely be representative. In that way, TDD sits in a very similar brain-space for me as Scrum does. Useful foundations, utter nonsense if taken to extremes, unsure if a net-positive influence (globally, not personally) in the end. I have seen a looooot of negative-value tests, in ever-increasing quantity as time goes on, in the name of TDD.
  - Jtsummers 4y ago
    As a partial defense for the length of the book, it was "Test-Driven Development by Example". Hard to fit examples into the page or two needed to explain the core concept itself. Letting ideas like this move into the "similar brain-space ... as Scrum" is dangerous. You're actively choosing not to think at that point, you're choosing anti-thought over thought. Move too many things into that brain-space and you're going to become thoughtless. Don't let that happen, you have more to contribute to the world than becoming another mindless automaton. Engage with the idea instead, understand why it does or does not make sense to you. Why it is or is not applicable to some area. Why other people have different ideas about it or disagree on its applicability. You'll be much better for it. And as much as I also dislike Scrum, it's worth engaging with its core ideas as well.
    - Groxx 4y ago
      I think you may be reading too much into my Scrum brain-space. Or maybe projecting? I've looked at those things. Found what I think are the core valuable bits, and how they apply to me and my situation. And I do not want to interact with them in a professional setting, because they are almost always distorted beyond any reasonable interpretation of their core, losing all meaning of the term and being used as an excuse to continue bad behaviors. They're quite similar in that respect.