5 ms·

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'

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)

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)