8 ms·

Tdd won't take off until developers realise they need to start thinking more. If you don't understand the problem you're trying to solve well enough to write t

by LandR 8y ago

Tdd won't take off until developers realise they need to start thinking more. If you don't understand the problem you're trying to solve well enough to write tests, you shouldn't start coding. But too many developers just want to dive in and hack code together and try to figure it out as they go. The resultant code from this is almost always a tire fire. Someone on hn a whole ago posted the quote "coding should be to software development what moving the pieces is to playing chess" I couldn't agree more. I wish more developers would get this.

war1025 8y ago
I don't do TDD because for the types of code I generally write, it is much easier to test the general cases back running the code directly. It's not that I don't have tests in mind when writing the code, it's that the tests I am working against are behavior driven, so it is easiest to just perform the actions myself and see where it falls down. Particularly in UI code, TDD seems to lead to code that is "technically correct", but produces a UI that is an absolute pain in the ass to do anything with. Tests have their place, but the proper time in the dev process to write them is very much a personal preference thing and nothing more.
- querulous 8y ago
  my experience is the exact opposite. ui code is where tdd shines the most because your spec is almost always 'when a user presses this button/fills this form/navigates to this page of the app do this thing'. there's zero uncertainty in the expected behavior so you can start out by writing exactly that test
  - war1025 8y ago
    Which is what I mean by leading you to "technically correct" code. At the end of it, you have everything wired up in a way that exposes the functionality, but you haven't necessarily spent any time testing out the ergonomics of actually using the UI. Could just be the people I've worked with aren't good at UI design.
    - querulous 8y ago
      i mean your tests should cover the ergonomics too. that should be the first thing you test, in fact. if you can't describe how it should work, you shouldn't even be opening an editor
- LandR 8y ago
  I do a lot of ui stuff and the sort of test I'd write for say a form and a save button would be: 1) populate the form with invalid data, click save. Verify that I showed an error message and it was structured how I want it. Verify I didn't call the database save. 2) populate the form with valid data, click save. Verify no error was shown, verify we called save on the dB layer and that the model we passed to save was as expected. Verify we showed the user a confirmation. 3) if we have required and non required fields, a test to verify each required field is actually required. If its not required verify the correct defaults are used. 4) if we are passing messages on save yo update other ui forms, then verify the message was sent and the underlying object or collection on the other ui element is updated with expected values. I would expect these tests to run on every build, and on your dev machine on every save. Otherwise you are just hoping devs arent breaking stuff... And hoping they test each case. Which for even a trivial form can be numerous. I'd definitly want this automated!
  - war1025 8y ago
    I also write those sorts of tests. I just write them after I am happy with the way things are working. Like I said, tests have their place. When to write them is just personal preference.
- dragonwriter 8y ago
  > Particularly in UI code, TDD seems to lead to code that is "technically correct", but produces a UI that is an absolute pain in the ass to do anything with. TDD (or ATDD or BDD; unit testing tends to be removed from the level of UI concern here) is not a substitute for UI design, at most it validates that the UI correctly implements the specifications given. This is not a problem with TDD/ATDD/BDD for UI-related components, it is a problem of neglecting UI design. (The same true, mutatis mutandis, of every other part of a system, too; development driven by building executable tests and the coding to pass those tests, in any of it's forms, is not a substitute for analysis and design but a tool to assure that implementation matches the design and does not do work unnecessary to fulfilling the design.)
  - war1025 8y ago
    Maybe that is part of the disconnect then. If some people either aren't responsible for the design portion, or don't include it in the "development" process, then I see how TDD could work pretty well. High level design has to come before specifics, and I don't think writing tests is the way to do that (unless you are counting things like acceptance tests, which seem like a different beast to me)
quanticle 8y ago
If you don't understand the problem you're trying to solve well enough to write tests, you shouldn't start coding. Sometimes there are problems that are only really possible to appreciate after one starts coding. In many instances, I've found that attempting to build a prototype is the best way to understand the problem. In those instances, TDD is a huge mistake. It ties you to architectural decisions that you know you're going to change when you better understand the problem. Contrast Ron Jeffries' attempt to build a sudoku solver using TDD with Peter Norvig's attempt [1]. [1]: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...
- voodootrucker 8y ago
  Peter Norvig's approach seems like the textbook way to TDD: 1. Find a large body of known good input/output pairs 2. create tests around that known good data 3. create an implementation that produces the desired output from the given input There's no reason Peter couldn't or shouldn't have started with the tests.
  - quanticle 8y ago
    What you're describing is closer to what Ron Jeffries attempted than to what Peter Norvig did. It's Jeffries who started with input and output and then faffed about for five blog posts while attempting to figure out a way to get input to match output. What Norvig did was start by thinking about the representation of the problem and the constraints that the problem imposed. He then found a way to elegantly represent those constraints in code. And, only then did he write tests. Moreover, the process you describe is quite similar to the parody of "how to draw an owl" [1]. It completely glosses over the fact that "create an implementation that produces the desired output from the given input" is where 99.5% of the complexity lies. [1]: https://i.kym-cdn.com/photos/images/newsfeed/000/572/078/d6d.jpg https://i.kym-cdn.com/photos/images/newsfeed/000/572/078/d6d...
- jacques_chester 8y ago
  That a practice is not universally valuable is different from whether a practice is universally worthless. TDD has a sweet spot and by itself is not enough. "Reinventing computer science, one test at a time" is a joke I've heard at Pivotal about Pivotal. And it's sometimes true. There is a lot of valuable work in the TDD sweetspot. There is also a lot of work to be done on a whiteboard. Neither is a perfect substitute for the other. You profit from having both.

by LandR 8y ago

war1025 8y ago

I don't do TDD because for the types of code I generally write, it is much easier to test the general cases back running the code directly. It's not that I don't have tests in mind when writing the code, it's that the tests I am working against are behavior driven, so it is easiest to just perform the actions myself and see where it falls down. Particularly in UI code, TDD seems to lead to code that is "technically correct", but produces a UI that is an absolute pain in the ass to do anything with. Tests have their place, but the proper time in the dev process to write them is very much a personal preference thing and nothing more.

querulous 8y ago
my experience is the exact opposite. ui code is where tdd shines the most because your spec is almost always 'when a user presses this button/fills this form/navigates to this page of the app do this thing'. there's zero uncertainty in the expected behavior so you can start out by writing exactly that test
- war1025 8y ago
  Which is what I mean by leading you to "technically correct" code. At the end of it, you have everything wired up in a way that exposes the functionality, but you haven't necessarily spent any time testing out the ergonomics of actually using the UI. Could just be the people I've worked with aren't good at UI design.
  - querulous 8y ago
    i mean your tests should cover the ergonomics too. that should be the first thing you test, in fact. if you can't describe how it should work, you shouldn't even be opening an editor
LandR 8y ago
I do a lot of ui stuff and the sort of test I'd write for say a form and a save button would be: 1) populate the form with invalid data, click save. Verify that I showed an error message and it was structured how I want it. Verify I didn't call the database save. 2) populate the form with valid data, click save. Verify no error was shown, verify we called save on the dB layer and that the model we passed to save was as expected. Verify we showed the user a confirmation. 3) if we have required and non required fields, a test to verify each required field is actually required. If its not required verify the correct defaults are used. 4) if we are passing messages on save yo update other ui forms, then verify the message was sent and the underlying object or collection on the other ui element is updated with expected values. I would expect these tests to run on every build, and on your dev machine on every save. Otherwise you are just hoping devs arent breaking stuff... And hoping they test each case. Which for even a trivial form can be numerous. I'd definitly want this automated!
- war1025 8y ago
  I also write those sorts of tests. I just write them after I am happy with the way things are working. Like I said, tests have their place. When to write them is just personal preference.
dragonwriter 8y ago
> Particularly in UI code, TDD seems to lead to code that is "technically correct", but produces a UI that is an absolute pain in the ass to do anything with. TDD (or ATDD or BDD; unit testing tends to be removed from the level of UI concern here) is not a substitute for UI design, at most it validates that the UI correctly implements the specifications given. This is not a problem with TDD/ATDD/BDD for UI-related components, it is a problem of neglecting UI design. (The same true, mutatis mutandis, of every other part of a system, too; development driven by building executable tests and the coding to pass those tests, in any of it's forms, is not a substitute for analysis and design but a tool to assure that implementation matches the design and does not do work unnecessary to fulfilling the design.)
- war1025 8y ago
  Maybe that is part of the disconnect then. If some people either aren't responsible for the design portion, or don't include it in the "development" process, then I see how TDD could work pretty well. High level design has to come before specifics, and I don't think writing tests is the way to do that (unless you are counting things like acceptance tests, which seem like a different beast to me)

quanticle 8y ago

If you don't understand the problem you're trying to solve well enough to write tests, you shouldn't start coding. Sometimes there are problems that are only really possible to appreciate after one starts coding. In many instances, I've found that attempting to build a prototype is the best way to understand the problem. In those instances, TDD is a huge mistake. It ties you to architectural decisions that you know you're going to change when you better understand the problem. Contrast Ron Jeffries' attempt to build a sudoku solver using TDD with Peter Norvig's attempt [1]. [1]: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...

voodootrucker 8y ago
Peter Norvig's approach seems like the textbook way to TDD: 1. Find a large body of known good input/output pairs 2. create tests around that known good data 3. create an implementation that produces the desired output from the given input There's no reason Peter couldn't or shouldn't have started with the tests.
- quanticle 8y ago
  What you're describing is closer to what Ron Jeffries attempted than to what Peter Norvig did. It's Jeffries who started with input and output and then faffed about for five blog posts while attempting to figure out a way to get input to match output. What Norvig did was start by thinking about the representation of the problem and the constraints that the problem imposed. He then found a way to elegantly represent those constraints in code. And, only then did he write tests. Moreover, the process you describe is quite similar to the parody of "how to draw an owl" [1]. It completely glosses over the fact that "create an implementation that produces the desired output from the given input" is where 99.5% of the complexity lies. [1]: https://i.kym-cdn.com/photos/images/newsfeed/000/572/078/d6d.jpg https://i.kym-cdn.com/photos/images/newsfeed/000/572/078/d6d...
jacques_chester 8y ago
That a practice is not universally valuable is different from whether a practice is universally worthless. TDD has a sweet spot and by itself is not enough. "Reinventing computer science, one test at a time" is a joke I've heard at Pivotal about Pivotal. And it's sometimes true. There is a lot of valuable work in the TDD sweetspot. There is also a lot of work to be done on a whiteboard. Neither is a perfect substitute for the other. You profit from having both.