4 ms·

> And if the director of a movie has asked you write some code to 3D render a "really awesome-looking explosion" you won't benefit much from unit tests either,

> And if the director of a movie has asked you write some code to 3D render a "really awesome-looking explosion" you won't benefit much from unit tests either, unless you can write a unit test to determine awesomeness. I was skeptical of this post to begin with but this line sums it up for me. The author is railing against a perceived threat. Of course you can't unit test _awesome_. That's ridiculous. So what's the claim here? I think more developers need to be introduced to the concept of the, "state of the art," and be led to resources like SWEBOK[0]. It has a section on software testing and it's good to know what the state of the art is across the industry. I don't have the link in my db, but I've come across studies that have shown no significant difference in productivity when utilizing test-first vs. test-after approaches to software development. That's the only real religious sell I still hear these days and it has been rather well debunked at this point. All that matters is that software is tested... how you approach it seems to just be a matter personal preference. [0] https://www.computer.org/web/swebok/v3 https://www.computer.org/web/swebok/v3

z3t4 10y ago
I write the test before fixing the bug, so I can automatically repeat the bug, and make sure the test finds the bug.
- spdionis 10y ago
  Assuming you're fixing a bug...
nickbauman 10y ago
I find that systems written with few tests are inordinately hard to add tests to. So I tell people "please TDD" because if they don't, the tests are never backfilled.
- agentultra 10y ago
  This is a common occurrence. The practice of writing tests shouldn't be avoided. You still have to write the unit tests which implies your code must also be testable. The difference in productivity between "write the test first," and "write the test after you've written a bit of code," don't seem to matter as much as "write the tests." As someone who reviews code for a good portion of my day it makes little difference to me how you, the programmer, managed to write the tests. We share the same goals and the end result seems to matter more than how it was accomplished.
  - josteink 10y ago
    I think the "test-first" approach has more focus on ensuring you don't write any production-code until you have formalized the requirements for that piece of business-logic. If you write the tests afterwards, it's hard(er) to know if you've managed to retro-actively cover all the formal requirements. And that makes it harder to later on trust that the tests will cover your ass entirely (as far as formalized business-requirements go). I can definitely see the appeal, but I'll be the first to admit I don't go the full mile myself, always. And that's I guess what this blog-post is all about. Be critical about how you apply well-meant advice.
    - agentultra 10y ago
      > I think the "test-first" approach has more focus on ensuring you don't write any production-code until you have formalized the requirements for that piece of business-logic. In fact the SWEBOK 3.0 section on test-driven design mentions this. It was first proposed in extreme programming as an alternative to more formal specification methods. > I can definitely see the appeal, but I'll be the first to admit I don't go the full mile myself, always. And that's I guess what this blog-post is all about. Be critical about how you apply well-meant advice. As banal as such advice is if that is as far as the article went I'd be fine with that. However the argument was weakened when the author eschewed unit tests out of, what appears to be, ignorance. I don't always write tests first either... when I'm prototyping I'll usually try a few approaches first. However I generally throw out that code once I find a tack I want to take and begin specifying the interfaces, constrains, and invariants through tests. In higher-level languages with sound type systems I generally rely on properties of the type system and compiler in lieu of tests I'd write in a more dynamic environment. It's just a matter of preference that I tend to think more before I write code and write tests first.
heimidal 10y ago
The question is, how do those studies measure productivity? In my case, I've found I write more readable, easier to understand code when I use tests to drive out my design. It may actually take more time to write the code itself, but the product ends up better, imo. (Granted, I think I take the approach this article advocates and only do so when I can help inform the design.)
- mcphage 10y ago
  > In my case, I've found I write more readable, easier to understand code when I use tests to drive out my design. In my case, I've found the opposite—when I use tests to drive my design, I end up with lots of tiny moving parts; each one individually is understandable, but the design as a whole is not, and figuring out how to do anything different is an exercise in frustration. I end up jumping between 2 or 3 files, trying to figure out where anything happens, because it's all been unit tested into perfect isolated pieces.
- z3t4 10y ago
  I think that when you need to test the code the naive solution is to write less complexed code, witch is a win in itself. In some cases you can get rid of all couplings/complexity and state, so that the code/function/unit never breaks, and writing automated tests for those becomes kinda unnecessary.
josteink 10y ago
> I was skeptical of this post to begin with but this line sums it up for me. The author is railing against a perceived threat. Of course you can't unit test _awesome_. That's ridiculous. You'd be surprised. When I advocate unit-tests, I often get the question back "But how do we unit-test this GUI-code?". Which, as you point out, is ridiculous. But they still ask the question. The truth is that these people have inter-twined their GUI-code and business-logic (and maybe even DB-access code) and they don't even realize that this is a code-smell. They don't see how they can apply unit-testing to their code, because they haven't realized that their code should be divided into smaller, independent units. To "convert" these people (to further reiterate the religious analogy) you first need to convince them that you're not actually crazy. Towards that end, this might be a start.

z3t4 10y ago

I write the test before fixing the bug, so I can automatically repeat the bug, and make sure the test finds the bug.

spdionis 10y ago
Assuming you're fixing a bug...

nickbauman 10y ago

I find that systems written with few tests are inordinately hard to add tests to. So I tell people "please TDD" because if they don't, the tests are never backfilled.

agentultra 10y ago
This is a common occurrence. The practice of writing tests shouldn't be avoided. You still have to write the unit tests which implies your code must also be testable. The difference in productivity between "write the test first," and "write the test after you've written a bit of code," don't seem to matter as much as "write the tests." As someone who reviews code for a good portion of my day it makes little difference to me how you, the programmer, managed to write the tests. We share the same goals and the end result seems to matter more than how it was accomplished.
- josteink 10y ago
  I think the "test-first" approach has more focus on ensuring you don't write any production-code until you have formalized the requirements for that piece of business-logic. If you write the tests afterwards, it's hard(er) to know if you've managed to retro-actively cover all the formal requirements. And that makes it harder to later on trust that the tests will cover your ass entirely (as far as formalized business-requirements go). I can definitely see the appeal, but I'll be the first to admit I don't go the full mile myself, always. And that's I guess what this blog-post is all about. Be critical about how you apply well-meant advice.
  - agentultra 10y ago
    > I think the "test-first" approach has more focus on ensuring you don't write any production-code until you have formalized the requirements for that piece of business-logic. In fact the SWEBOK 3.0 section on test-driven design mentions this. It was first proposed in extreme programming as an alternative to more formal specification methods. > I can definitely see the appeal, but I'll be the first to admit I don't go the full mile myself, always. And that's I guess what this blog-post is all about. Be critical about how you apply well-meant advice. As banal as such advice is if that is as far as the article went I'd be fine with that. However the argument was weakened when the author eschewed unit tests out of, what appears to be, ignorance. I don't always write tests first either... when I'm prototyping I'll usually try a few approaches first. However I generally throw out that code once I find a tack I want to take and begin specifying the interfaces, constrains, and invariants through tests. In higher-level languages with sound type systems I generally rely on properties of the type system and compiler in lieu of tests I'd write in a more dynamic environment. It's just a matter of preference that I tend to think more before I write code and write tests first.

heimidal 10y ago

The question is, how do those studies measure productivity? In my case, I've found I write more readable, easier to understand code when I use tests to drive out my design. It may actually take more time to write the code itself, but the product ends up better, imo. (Granted, I think I take the approach this article advocates and only do so when I can help inform the design.)

mcphage 10y ago
> In my case, I've found I write more readable, easier to understand code when I use tests to drive out my design. In my case, I've found the opposite—when I use tests to drive my design, I end up with lots of tiny moving parts; each one individually is understandable, but the design as a whole is not, and figuring out how to do anything different is an exercise in frustration. I end up jumping between 2 or 3 files, trying to figure out where anything happens, because it's all been unit tested into perfect isolated pieces.
z3t4 10y ago
I think that when you need to test the code the naive solution is to write less complexed code, witch is a win in itself. In some cases you can get rid of all couplings/complexity and state, so that the code/function/unit never breaks, and writing automated tests for those becomes kinda unnecessary.

josteink 10y ago

> I was skeptical of this post to begin with but this line sums it up for me. The author is railing against a perceived threat. Of course you can't unit test _awesome_. That's ridiculous. You'd be surprised. When I advocate unit-tests, I often get the question back "But how do we unit-test this GUI-code?". Which, as you point out, is ridiculous. But they still ask the question. The truth is that these people have inter-twined their GUI-code and business-logic (and maybe even DB-access code) and they don't even realize that this is a code-smell. They don't see how they can apply unit-testing to their code, because they haven't realized that their code should be divided into smaller, independent units. To "convert" these people (to further reiterate the religious analogy) you first need to convince them that you're not actually crazy. Towards that end, this might be a start.