5 ms·

I found TDD useful for a well defined problem or an agreed-upon API. For apps for example, especially those not well defined and designed as-you-go, where the d

I found TDD useful for a well defined problem or an agreed-upon API. For apps for example, especially those not well defined and designed as-you-go, where the designer and PM might change their minds frequently after toying around with the app or getting user feedback, TDD is a lot of overhead and tests after writing the code are primarily useful for preventing regressions when somebody else changes your code.

jacobsenscott 5y ago
I hear this a lot, but the result is usually an untested, and usually nearly untestable (because it was written without tests), prototype with a few characterization tests that gets pushed to production and haunts you for the rest of the life of the product. Pototyping to define the problem or API is fine, but most people don't have the discipline to tear it out and start over when they finally do have a well defined problem. It is somewhat unfathomable to me that you can have an idea if what production code to write, but no idea what test to write. Certainly you can "expect this page has a button" if you are about to add a button and write the test first. Or "expect this method to add a record to the database", etc. Certainly you are about to write code that does something, so just write a test to expect that thing to happen. Especially in the case where someone is changing their mind all the time, you are dead in the water without tests to support your changes. You need to manually re-test everything every time they change their mind. Testing after the fact is not that useful for catching regressions because it is unlikely enough tests will be written due to pressure to release. Also a much greater percentage of the tests written after the production code tend to be vacuous tests.
- brabel 5y ago
  > the result is usually an untested, and usually nearly untestable No way... if you ever wrote any tests, you can easily know how to write code that will be testable even if you do it later. Doing it before is just going to be a big waste of time if you throw the code away later, which happens a lot when you need to experiment with things before actually choosing what works best. Yes, you can do that with TDD as well but it will absolutely slow you down. If you end up not writing tests later, when the implementation has been chosen, it's just because you don't care about the code quality... I find it hard to believe TDD will fix you in that case.
  - regularfry 5y ago
    Swings and roundabouts: what you lose on writing tests you gain on not bothering to implement things you don't need. If the test passes, you stop. Without the tests to guide you it's very easy to waste time over-engineering, even if what you're building is well-structured.
    - brabel 5y ago
      I often write code without implementing anything, just the "surface API". That's when I find whether things will work or not. Tests are a hindrance to that. Once I figure out the design, then I will test all that I think is important. > what you lose on writing tests you gain on not bothering to implement things you don't need. I am not sure where to start... I've written so much code, applications, libraries, algorithms... and I am pretty sure the opposite of what you say is true: with TDD, I would've spent hours trying to get something working that later I would find, by exploration, that I didn't need at all.
      - regularfry 5y ago
        > I often write code without implementing anything, just the "surface API". That's when I find whether things will work or not. There's an entire school of TDD which works this way. That's not incompatible at all. > with TDD, I would've spent hours trying to get something working that later I would find, by exploration, that I didn't need at all. If you're writing tests for something you don't need, the problem isn't with TDD as I understand it.
  - berkes 5y ago
    I've always experienced that writing the actual code is but a minor part of building features (or fixing bugs). Especially when prototyping, which most often is merely ducttaping libs together. Everyone remembers a bugfix of one line, that took hours, or days to find. I'd stringly encourage you to check your commitlogs. You'll probably find you commit at most hundreds of lines a day, quite probably, as is my case too, av era aging under ten lines a day. Please stop thinking that writing code which does not make it into commits, is waste. It is learning. And tests are by far the best place to learn about your, and Libs' code, APIs and behaviour.
porker 5y ago
This is my experience too (business/customer facing CRUD systems). Perhaps we don't spend long enough thinking about the problem before we start or planning enough, but most software I write starts with a business problem that needs a solution and data, inputs and processes will evolve as it's written. Normally because what comes out in business analysis and stakeholder interviews is close to but not quite what is wanted, but also because of user feedback from user testing (sometimes of a mockup, sometimes prototype software) which is so valuable but now the inputs change again. I enjoy writing tests when developing libraries where the inputs and outputs are well defined. It's relaxing to do this kind of programming.
4140tm 5y ago
You don't need precise specs to practice TDD. If you have idea of the code you need to write, you can write the test for it beforehand - no matter how often someone might change their mind about the app. Doing so would actually make your life a lot easier when it's time to alter functionality, because now you have well tested and testable code. Code that is written to be tested is usually a lot easier to reason about, to change and extend. If you do it in concise manner and test behavior rather than implementation, what you previously thought of overhead will actually speed you up.
- berkes 5y ago
  Tests are also meant to be continously refactored, though.
jbergens 5y ago
For prototyping TDD may be waste. If you are just trying different ux and different logic it may not help to test. For almost everything else I think it helps.

jacobsenscott 5y ago

I hear this a lot, but the result is usually an untested, and usually nearly untestable (because it was written without tests), prototype with a few characterization tests that gets pushed to production and haunts you for the rest of the life of the product. Pototyping to define the problem or API is fine, but most people don't have the discipline to tear it out and start over when they finally do have a well defined problem. It is somewhat unfathomable to me that you can have an idea if what production code to write, but no idea what test to write. Certainly you can "expect this page has a button" if you are about to add a button and write the test first. Or "expect this method to add a record to the database", etc. Certainly you are about to write code that does something, so just write a test to expect that thing to happen. Especially in the case where someone is changing their mind all the time, you are dead in the water without tests to support your changes. You need to manually re-test everything every time they change their mind. Testing after the fact is not that useful for catching regressions because it is unlikely enough tests will be written due to pressure to release. Also a much greater percentage of the tests written after the production code tend to be vacuous tests.

brabel 5y ago
> the result is usually an untested, and usually nearly untestable No way... if you ever wrote any tests, you can easily know how to write code that will be testable even if you do it later. Doing it before is just going to be a big waste of time if you throw the code away later, which happens a lot when you need to experiment with things before actually choosing what works best. Yes, you can do that with TDD as well but it will absolutely slow you down. If you end up not writing tests later, when the implementation has been chosen, it's just because you don't care about the code quality... I find it hard to believe TDD will fix you in that case.
- regularfry 5y ago
  Swings and roundabouts: what you lose on writing tests you gain on not bothering to implement things you don't need. If the test passes, you stop. Without the tests to guide you it's very easy to waste time over-engineering, even if what you're building is well-structured.
  - brabel 5y ago
    I often write code without implementing anything, just the "surface API". That's when I find whether things will work or not. Tests are a hindrance to that. Once I figure out the design, then I will test all that I think is important. > what you lose on writing tests you gain on not bothering to implement things you don't need. I am not sure where to start... I've written so much code, applications, libraries, algorithms... and I am pretty sure the opposite of what you say is true: with TDD, I would've spent hours trying to get something working that later I would find, by exploration, that I didn't need at all.
    - regularfry 5y ago
      > I often write code without implementing anything, just the "surface API". That's when I find whether things will work or not. There's an entire school of TDD which works this way. That's not incompatible at all. > with TDD, I would've spent hours trying to get something working that later I would find, by exploration, that I didn't need at all. If you're writing tests for something you don't need, the problem isn't with TDD as I understand it.
- berkes 5y ago
  I've always experienced that writing the actual code is but a minor part of building features (or fixing bugs). Especially when prototyping, which most often is merely ducttaping libs together. Everyone remembers a bugfix of one line, that took hours, or days to find. I'd stringly encourage you to check your commitlogs. You'll probably find you commit at most hundreds of lines a day, quite probably, as is my case too, av era aging under ten lines a day. Please stop thinking that writing code which does not make it into commits, is waste. It is learning. And tests are by far the best place to learn about your, and Libs' code, APIs and behaviour.

porker 5y ago

This is my experience too (business/customer facing CRUD systems). Perhaps we don't spend long enough thinking about the problem before we start or planning enough, but most software I write starts with a business problem that needs a solution and data, inputs and processes will evolve as it's written. Normally because what comes out in business analysis and stakeholder interviews is close to but not quite what is wanted, but also because of user feedback from user testing (sometimes of a mockup, sometimes prototype software) which is so valuable but now the inputs change again. I enjoy writing tests when developing libraries where the inputs and outputs are well defined. It's relaxing to do this kind of programming.

4140tm 5y ago

You don't need precise specs to practice TDD. If you have idea of the code you need to write, you can write the test for it beforehand - no matter how often someone might change their mind about the app. Doing so would actually make your life a lot easier when it's time to alter functionality, because now you have well tested and testable code. Code that is written to be tested is usually a lot easier to reason about, to change and extend. If you do it in concise manner and test behavior rather than implementation, what you previously thought of overhead will actually speed you up.

berkes 5y ago
Tests are also meant to be continously refactored, though.

jbergens 5y ago

For prototyping TDD may be waste. If you are just trying different ux and different logic it may not help to test. For almost everything else I think it helps.