5 ms·

As both a TDD and HN fan I'm really quite surprised to hear the anti TDD rhetoric here. To the detractors here are some honest questions: 1) How many projects

by ollysb 16y ago

As both a TDD and HN fan I'm really quite surprised to hear the anti TDD rhetoric here. To the detractors here are some honest questions: 1) How many projects have you worked on that were 100% test driven and written outside-in? 2) Do you have the knowledge to test any code, regardless of web APIs, filesystem etc.? 3) When you deploy an app without 100% coverage how can you be confident that there are no regressions? 4) When you add new functionality are you comfortable changing the existing code or do you try to leave it alone and build on top of it?

britman 16y ago
I take a pragmatic approach to Unit tests so find some use but don't feel the 100% gold standard of coverage is realistic or even sensible to aspire too but in response to Q3) never - but then I'd return the question When you deploy an app WITH 100% coverage how can you be confident that there are no regressions? I'm pretty sure the answer is never too as 100% test coverage doesn't prevent 100% of bugs.
moconnor 16y ago
I like TDD, but it has its place. I think you'll find the rhetoric here is a reaction to the inflammatory tone in the article more than anything else. It's perfectly possible to develop and maintain large, complex systems without 100% code coverage. Clearly some level of testing coverage between 0% and 100% is optimal. The case for it being 100% is, to my mind, extremely weak.
- tuomas-mbm 16y ago
  A bit out of topic, but what is it that makes the article to have "inflammatory tone"? Would love to hear some feedback about this too to improve my writing skills.
  - ollysb 16y ago
    It's effectively said that anyone that doesn't practice TDD isn't professional. Telling people they're unprofessional tends to piss them off :) edit: In response to child post - That was my interpretation of this "It will make our work so much more efficient, motivating and a bit more professional."
    - tuomas-mbm 16y ago
      I have to admit that I have a bad habit to write things a bit extreme way to start a conversation. How ever where did I do such a claim that if one does not do TDD is not professional? It seems that I definitely need to improve my English. :)
- deleted 16y ago
  [deleted]
- ollysb 16y ago
  I wouldn't want to maintain a large, complex system without a high coverage percentage. I'd have thought that would seriously hit your velocity.
jared314 16y ago
There is no such thing as 100% test driven and 100% coverage.
- ollysb 16y ago
  I should clarify what I mean by 100% test driven. By this I mean that no line of code was written without first having a test written for it. While you can't practically achieve 100% coverage of all code paths you can at least exercise all of the expected code paths.
efsavage 16y ago
1. None. 2. Yes. 3. Confident? - Yes. Guaranteed? - No, nor would it be with 100% coverage either. 4. Absolutely (Java + Eclipse + proper use of Exceptions). Somethings need/should be unit tested, but most "glue" code benefits far more from investing time in robust error handling rather than testing.
- ollysb 16y ago
  The difficulty I have here is that you associate unit testing with a large time cost. If you had good TDD knowledge then the length of time it takes to write a test is only slightly longer than it would take you to think about exactly what your code should be doing. In java I find unit testing is actually a huge time saver as I don't need to keep starting/stopping a server to find out if some code works correctly. With the dynamic languages the feedback loop is much shorter so it's not so relevant. Admittedly I've never used javarebel which would render this a moot point.
  - stonemetal 16y ago
    in java I find unit testing is actually a huge time saver as I don't need to keep starting/stopping a server to find out if some code works correctly. There in lies the problem. It isn't unit test vs full up build an installer, and run the server. Those are just the two ends of the spectrum.
    - ollysb 16y ago
      How could you be anywhere but at one end of the spectrum or the other with java? There's no REPL available so how else would you exercise code?
      - stonemetal 16y ago
        I use a unit test framework to write tests. These tests take a logical component and test the interface it provides to the rest of the application. I do this for every logical component certainly not every individual class and I certainly don't write a bunch of fake code to pretend like the rest of the app works. I don't care if my code works when provided with a bunch of mocks and stubs I care weather or not my code works with the rest of the system. The only way to call it unit testing is if you make unit mean something completely different to what most people mean by unit. Yet it is automated testing that covers real functionality.
deleted 16y ago
[deleted]
- ollysb 16y ago
  Kent Beck - "Before [market fit] you need the absolute lowest possible latency from idea through implementation to validation. ... Sometimes this means no automated tests." I think this is a great point and perhaps explains the low support for TDD on HN. In my experience the properties of a TDD project are: consistent flow rate of business value, low regression rate, low QA cost (assuming integration tests). It's the consistent flow rate which is perhaps most interesting. At the start of a non TDD project it's easy to achieve a high velocity without tests. As the length of time from the start of the project increases the velocity will inevitably decline due to the increased complexity of the project and the greater level of QA required. Over a longer period the project without tests is going to tend towards a slower velocity until eventuality it hits a wall and it's big rewrite time. For a TDD project the velocity curve is going to be different. You're going to see a slower start but once a velocity has been established it tends to stay fairly flat or increase. The XP guys talk about hyper-productive teams, there's no guarantee but you're far more likely to hit this point with a TDD project. Increasing the number of features a product has and the number of team members will only exaggerate these two velocity curves. There's another factor here as well, the knowledge of TDD within a team. The greater the TDD experience the smaller the difference will be in the starting velocity. With enough experience the velocity hit becomes small enough that the two curves can cross over very quickly. The choice of strategy then becomes: are the velocity curves likely to cross over before or after you achieve market fit? Not an easy question to answer and one which is easy to ignore when everyone is excited about just getting something built. edit: not sure what happened to the parent post, here's a link to Kent Beck's comments about testing before market fit http://www.quora.com/What-kind-of-automated-testing-should-a-startup-have-from-the-beginning-through-the-first-six-months-of-live-operation http://www.quora.com/What-kind-of-automated-testing-should-a...

by ollysb 16y ago

britman 16y ago

I take a pragmatic approach to Unit tests so find some use but don't feel the 100% gold standard of coverage is realistic or even sensible to aspire too but in response to Q3) never - but then I'd return the question When you deploy an app WITH 100% coverage how can you be confident that there are no regressions? I'm pretty sure the answer is never too as 100% test coverage doesn't prevent 100% of bugs.

moconnor 16y ago

I like TDD, but it has its place. I think you'll find the rhetoric here is a reaction to the inflammatory tone in the article more than anything else. It's perfectly possible to develop and maintain large, complex systems without 100% code coverage. Clearly some level of testing coverage between 0% and 100% is optimal. The case for it being 100% is, to my mind, extremely weak.

tuomas-mbm 16y ago
A bit out of topic, but what is it that makes the article to have "inflammatory tone"? Would love to hear some feedback about this too to improve my writing skills.
- ollysb 16y ago
  It's effectively said that anyone that doesn't practice TDD isn't professional. Telling people they're unprofessional tends to piss them off :) edit: In response to child post - That was my interpretation of this "It will make our work so much more efficient, motivating and a bit more professional."
  - tuomas-mbm 16y ago
    I have to admit that I have a bad habit to write things a bit extreme way to start a conversation. How ever where did I do such a claim that if one does not do TDD is not professional? It seems that I definitely need to improve my English. :)
deleted 16y ago
[deleted]
ollysb 16y ago
I wouldn't want to maintain a large, complex system without a high coverage percentage. I'd have thought that would seriously hit your velocity.

jared314 16y ago

There is no such thing as 100% test driven and 100% coverage.

ollysb 16y ago
I should clarify what I mean by 100% test driven. By this I mean that no line of code was written without first having a test written for it. While you can't practically achieve 100% coverage of all code paths you can at least exercise all of the expected code paths.

efsavage 16y ago

1. None. 2. Yes. 3. Confident? - Yes. Guaranteed? - No, nor would it be with 100% coverage either. 4. Absolutely (Java + Eclipse + proper use of Exceptions). Somethings need/should be unit tested, but most "glue" code benefits far more from investing time in robust error handling rather than testing.

ollysb 16y ago
The difficulty I have here is that you associate unit testing with a large time cost. If you had good TDD knowledge then the length of time it takes to write a test is only slightly longer than it would take you to think about exactly what your code should be doing. In java I find unit testing is actually a huge time saver as I don't need to keep starting/stopping a server to find out if some code works correctly. With the dynamic languages the feedback loop is much shorter so it's not so relevant. Admittedly I've never used javarebel which would render this a moot point.
- stonemetal 16y ago
  in java I find unit testing is actually a huge time saver as I don't need to keep starting/stopping a server to find out if some code works correctly. There in lies the problem. It isn't unit test vs full up build an installer, and run the server. Those are just the two ends of the spectrum.
  - ollysb 16y ago
    How could you be anywhere but at one end of the spectrum or the other with java? There's no REPL available so how else would you exercise code?
    - stonemetal 16y ago
      I use a unit test framework to write tests. These tests take a logical component and test the interface it provides to the rest of the application. I do this for every logical component certainly not every individual class and I certainly don't write a bunch of fake code to pretend like the rest of the app works. I don't care if my code works when provided with a bunch of mocks and stubs I care weather or not my code works with the rest of the system. The only way to call it unit testing is if you make unit mean something completely different to what most people mean by unit. Yet it is automated testing that covers real functionality.

deleted 16y ago

[deleted]

ollysb 16y ago
Kent Beck - "Before [market fit] you need the absolute lowest possible latency from idea through implementation to validation. ... Sometimes this means no automated tests." I think this is a great point and perhaps explains the low support for TDD on HN. In my experience the properties of a TDD project are: consistent flow rate of business value, low regression rate, low QA cost (assuming integration tests). It's the consistent flow rate which is perhaps most interesting. At the start of a non TDD project it's easy to achieve a high velocity without tests. As the length of time from the start of the project increases the velocity will inevitably decline due to the increased complexity of the project and the greater level of QA required. Over a longer period the project without tests is going to tend towards a slower velocity until eventuality it hits a wall and it's big rewrite time. For a TDD project the velocity curve is going to be different. You're going to see a slower start but once a velocity has been established it tends to stay fairly flat or increase. The XP guys talk about hyper-productive teams, there's no guarantee but you're far more likely to hit this point with a TDD project. Increasing the number of features a product has and the number of team members will only exaggerate these two velocity curves. There's another factor here as well, the knowledge of TDD within a team. The greater the TDD experience the smaller the difference will be in the starting velocity. With enough experience the velocity hit becomes small enough that the two curves can cross over very quickly. The choice of strategy then becomes: are the velocity curves likely to cross over before or after you achieve market fit? Not an easy question to answer and one which is easy to ignore when everyone is excited about just getting something built. edit: not sure what happened to the parent post, here's a link to Kent Beck's comments about testing before market fit http://www.quora.com/What-kind-of-automated-testing-should-a-startup-have-from-the-beginning-through-the-first-six-months-of-live-operation http://www.quora.com/What-kind-of-automated-testing-should-a...