4 ms·

It's free software. There is a large overhead when doing TDD. Such overhead is not practical given the low, voluntary, resources such projects get. Free softwar

by Elv13 13y ago

It's free software. There is a large overhead when doing TDD. Such overhead is not practical given the low, voluntary, resources such projects get. Free software project velocity is based on contributions. If you require such contributions to also make tests before committing the code, then you kill the project in a few months. This is why TDD based projects are so few and controversial in the FLOSS world.

Aqueous 13y ago
I think a common misconception about TDD is that it requires a a lot of overhead. It actually reduces overhead because you front-load the quality assurance, and save a lot of time going back and fixing bugs down the road. Some of the most popular open source projects use a lot of test coverage. Some very important projects don't, but I think the only reason Linux, for instance, has gotten away with this is because it has such a gigantic community that finds and fixes a bug immediately if one is found.
- pjmlp 13y ago
  How do you TDD UI code?
  - Aqueous 13y ago
    On the web, you can use Selenium and pair it with either a headless browser like PhantomJS and/or a headless virtual machine running IE.
    - pjmlp 13y ago
      How you validate if the CSS or HTML is rendered as supposed to be?
      - Aqueous 13y ago
        You look at it :-) (Edit: That's not the whole answer. Usually when you test you assert that certain elements of the DOM are where they should be. At the very least you have verified the structure of the HTML document, if not how it looks. For actual aesthetics I can't see any way around human testing.)
        pjmlp 13y ago
        I am just playing devil's advocate. I work for Fortune 500 consulting projects and don't believe in TDD for UI code that works across the myriad of technologies we use in work projects, while scaling across multi-site development. TDD only seems to work on the business logic, and only in code written with testing in mind.
      - quadhome 13y ago
        You have the computer look at it. Brett Slatkin of Google Consumer Surveys has a great talk on using perceptual diffs for this: https://air.mozilla.org/continuous-delivery-at-google/ https://air.mozilla.org/continuous-delivery-at-google/
  - sethrin 13y ago
    So hopefully you have a way of generating HTML/CSS that will throw errors if you have incorrect or missing data. Beyond that, rendering a lot of things on one page is a good strategy. Among other benefits, it forces you to modularize your code in order to be able to do that. It's also a hell of a lot more efficient to look at one page with 50 items to check that they all rendered correctly, than it is to check 50 pages.
    - zaphar 13y ago
      Great! Now how do you TDD KDE UI code?
      - sethrin 13y ago
        I am not entirely sure, but I think you GDB the STDOUT, grep the bin, and if that doesn't work, reroute the auxiliary phase array to the main deflectors. It works every time. I'm going to go out on a limb and say that if you write KDE UI code, you should be able to answer the question of how to test it, preferably in the automated sense. Notwithstanding all argument for and against TDD, the best proof of correctness is a long (manual) testing cycle.
        pjmlp 13y ago
        The thing is, there is yet to exist any tool that allows TDD of desktop UIs beyond the toy examples people come up with web applications at conferences.
      - lmm 13y ago
        The same way. KDE components are very modular, so it's trivial to write a UI form that displays a bunch of components from various parts of your code. You could write a second executable that just displays this test form with test data (most of your code should be written as a library anyway, so having two executables that call your components shouldn't be an issue). Of course more automation is better, so I'd probably want to write a selenium-equivalent for asserting things about a component tree. Again, the KDE components are very regular so it's easy to generically traverse/inspect a GUI. It's really not hard if you actually try.
dragonwriter 13y ago
> There is a large overhead when doing TDD. I don't think that's true. There may be a requirement to do unsexy tasks that volunteers aren't interested in, but the actual overhead to create software that works as intended is lower doing TDD than without it, which is the whole point of TDD.
- Elv13 13y ago
  That's the controversy. I do TDD at work and I don't for my contributions. I know both quite well. Most projects have little regressions and it is hard to quantify upfront time you will hypothetically save later on, especially if all you do is contributing and moving to something else. There is some projects where TDD is down right vital, but most of the time, it is not.
- zaphar 13y ago
  TDD creates a large maintenance overhead. It more than doubles the code that has to be maintained for the lifetime of the software. This is by design since any modification to the codebase should start with a modification to the tests. In reality though the tests often bitrot faster than the actual code does. The cost of the very large set of unittests generated by TDD only grows over time without contributing to the actual feature set of the software being developed. For this reason TDD does in fact introduce a large overhead with a potential savings in safety. The controversy is introduced when people start to realize that the most bang for the buck comes from tests that exercise the public interfaces of the various parts of the software and that less and less benefit comes from the tests covering the internal parts of the software. Often the fine grained tests covering the internal details cause the internals to ossify and increase the cost of changes until finally they get abandoned. TDD has it's place but taken too far it can do just as much harm as the lack of tests.
  - dragonwriter 13y ago
    > The controversy is introduced when people start to realize that the most bang for the buck comes from tests that exercise the public interfaces of the various parts of the software and that less and less benefit comes from the tests covering the internal parts of the software. That's not TDD being controversial, that's details of how to apply TDD being controversial at most (and, really, its seems to be a "controversy" that amounts to saying "doing things that TDD doesn't ever call for is excessive", with no other side, which isn't a controversy, its a non-sequitur; if you are creating unit tests for internal details that aren't exposed, you are preventing refactoring, rather than enabling by testing all and only the required exposed behavior so that you can refactor the implementation of that behavior without changing tests, which is a central part of TDD. I suspect the problem with this is bad metrics used by some people who say they are doing TDD but have adopted measurements that imply standards that forget about the entire point of TDD, such as looking to ensure that every method is directly tested, which is clearly inappropriate.)

by Elv13 13y ago

Aqueous 13y ago

I think a common misconception about TDD is that it requires a a lot of overhead. It actually reduces overhead because you front-load the quality assurance, and save a lot of time going back and fixing bugs down the road. Some of the most popular open source projects use a lot of test coverage. Some very important projects don't, but I think the only reason Linux, for instance, has gotten away with this is because it has such a gigantic community that finds and fixes a bug immediately if one is found.

pjmlp 13y ago
How do you TDD UI code?
- Aqueous 13y ago
  On the web, you can use Selenium and pair it with either a headless browser like PhantomJS and/or a headless virtual machine running IE.
  - pjmlp 13y ago
    How you validate if the CSS or HTML is rendered as supposed to be?
    - Aqueous 13y ago
      You look at it :-) (Edit: That's not the whole answer. Usually when you test you assert that certain elements of the DOM are where they should be. At the very least you have verified the structure of the HTML document, if not how it looks. For actual aesthetics I can't see any way around human testing.)
      - pjmlp 13y ago
        I am just playing devil's advocate. I work for Fortune 500 consulting projects and don't believe in TDD for UI code that works across the myriad of technologies we use in work projects, while scaling across multi-site development. TDD only seems to work on the business logic, and only in code written with testing in mind.
    - quadhome 13y ago
      You have the computer look at it. Brett Slatkin of Google Consumer Surveys has a great talk on using perceptual diffs for this: https://air.mozilla.org/continuous-delivery-at-google/ https://air.mozilla.org/continuous-delivery-at-google/
- sethrin 13y ago
  So hopefully you have a way of generating HTML/CSS that will throw errors if you have incorrect or missing data. Beyond that, rendering a lot of things on one page is a good strategy. Among other benefits, it forces you to modularize your code in order to be able to do that. It's also a hell of a lot more efficient to look at one page with 50 items to check that they all rendered correctly, than it is to check 50 pages.
  - zaphar 13y ago
    Great! Now how do you TDD KDE UI code?
    - sethrin 13y ago
      I am not entirely sure, but I think you GDB the STDOUT, grep the bin, and if that doesn't work, reroute the auxiliary phase array to the main deflectors. It works every time. I'm going to go out on a limb and say that if you write KDE UI code, you should be able to answer the question of how to test it, preferably in the automated sense. Notwithstanding all argument for and against TDD, the best proof of correctness is a long (manual) testing cycle.
      - pjmlp 13y ago
        The thing is, there is yet to exist any tool that allows TDD of desktop UIs beyond the toy examples people come up with web applications at conferences.
    - lmm 13y ago
      The same way. KDE components are very modular, so it's trivial to write a UI form that displays a bunch of components from various parts of your code. You could write a second executable that just displays this test form with test data (most of your code should be written as a library anyway, so having two executables that call your components shouldn't be an issue). Of course more automation is better, so I'd probably want to write a selenium-equivalent for asserting things about a component tree. Again, the KDE components are very regular so it's easy to generically traverse/inspect a GUI. It's really not hard if you actually try.

dragonwriter 13y ago

> There is a large overhead when doing TDD. I don't think that's true. There may be a requirement to do unsexy tasks that volunteers aren't interested in, but the actual overhead to create software that works as intended is lower doing TDD than without it, which is the whole point of TDD.

Elv13 13y ago
That's the controversy. I do TDD at work and I don't for my contributions. I know both quite well. Most projects have little regressions and it is hard to quantify upfront time you will hypothetically save later on, especially if all you do is contributing and moving to something else. There is some projects where TDD is down right vital, but most of the time, it is not.
zaphar 13y ago
TDD creates a large maintenance overhead. It more than doubles the code that has to be maintained for the lifetime of the software. This is by design since any modification to the codebase should start with a modification to the tests. In reality though the tests often bitrot faster than the actual code does. The cost of the very large set of unittests generated by TDD only grows over time without contributing to the actual feature set of the software being developed. For this reason TDD does in fact introduce a large overhead with a potential savings in safety. The controversy is introduced when people start to realize that the most bang for the buck comes from tests that exercise the public interfaces of the various parts of the software and that less and less benefit comes from the tests covering the internal parts of the software. Often the fine grained tests covering the internal details cause the internals to ossify and increase the cost of changes until finally they get abandoned. TDD has it's place but taken too far it can do just as much harm as the lack of tests.
- dragonwriter 13y ago
  > The controversy is introduced when people start to realize that the most bang for the buck comes from tests that exercise the public interfaces of the various parts of the software and that less and less benefit comes from the tests covering the internal parts of the software. That's not TDD being controversial, that's details of how to apply TDD being controversial at most (and, really, its seems to be a "controversy" that amounts to saying "doing things that TDD doesn't ever call for is excessive", with no other side, which isn't a controversy, its a non-sequitur; if you are creating unit tests for internal details that aren't exposed, you are preventing refactoring, rather than enabling by testing all and only the required exposed behavior so that you can refactor the implementation of that behavior without changing tests, which is a central part of TDD. I suspect the problem with this is bad metrics used by some people who say they are doing TDD but have adopted measurements that imply standards that forget about the entire point of TDD, such as looking to ensure that every method is directly tested, which is clearly inappropriate.)