5 ms·

It always startles me when people assume that one programming technique either works for every type of programming or doesn't work for every type. Working on P

It always startles me when people assume that one programming technique either works for every type of programming or doesn't work for every type. Working on Perl 6 compilers, an extensive set of tests was our best friend. It was (probably still is, I haven't had time to help the last few years) utterly routine to write tests first and then write the code to make them work. It was a perfect way of working on it. On the other hand, one of my personal projects in Perl 6 is abc2ly. It has lots of low level unit tests, great. But almost everything really interesting the program does is really hard to test programmatically. How would I write tests to make sure the sheet music PDF generated has all the correct notes and looks nice? That problem is significantly harder than generating the sheet music in the first place!

maxxxxx 9y ago
I also don't understand why people tend to elevate a technique that's very useful for some cases to a religion that needs to be followed always.
- sqeaky 9y ago
  People have a constrained view. They see their own problems and have seen the "old" way do nothing but fail and the "new" way do nothing but succeed. What other reaction would you expect? If they actively researched and looked beyond their personal experience then dramatic 0% to 100% Success rates would turn into more reasonable assessments. I think my view on TDD is more reasonable than most of the zealots, but I still like mant of the ideas of TDD a great deal. I don't think it much matters if the tests come before or after the code as long as they come early enough to save time and effort. This means that specification of some kind is required, without specification you can't do TDD. Once you have tests and some code, you can add more test to increase confidence and with confidence you can aggressively refactor. Sometimes its enough to write a minimal viable product and then write tests just so that refactoring for version 2 can be done reliably. I am doing something like this now for some C++ build system stuff... That sounds odd saying it loud, but yes I have cmake modules complex to need tests so I can be confident in refactoring them. But I didn't write any tests until the minimal viable version sort of work enough to have bugs filed against it. Now TDD on ethat project seems like great idea, when I didn't use any tests in the beginning (Partly because we couldn't specify what we wanted).
  - maxxxxx 9y ago
    " have seen the "old" way do nothing but fail and the "new" way do nothing but succeed." When I look at TDD I see a lot of success but also a lot of fail once people start pushing it too far. To me a fail is when the mock becomes more complex than the real system or a system can't be refactored because the refactoring of the tests takes too long or the tests are just so complex nobody wants to touch them. This reminds me a little of the situation with OOP. It solved a lot of real problems but then people said "only objects" and you ended up with stuff like replacing a simple switch statement and 100 easy to read lines of code with command patterns that had the implementation spread out over 10 different files.
    - sqeaky 9y ago
      I think you are totally correct both in your view that some take goods things too far and that this isn't the first time this pattern has been repeated. I wonder what things I am expounding now that I will pull back on in the future?
comstock 9y ago
It's interesting to me that programming is becoming a fundamental part of many (maybe most) things humans do. And yet we treat it as if there was one single correct way of programming and all other ways are wrong. I feel like it's much more akin to human language. Though the language primatives might be the same, it's used differently in different contexts are appropriate. In formal, legal speech, you might want to be explicit. In informal, everyday speech, not so much. Similar analogs exist in programming. 10 time script to reformat data for one time use, careful documentation, tests etc. not really required. Aircraft flight control system, very different... But then why is it that so many programmers seem to focus on "the one true way" (TDD, agile etc). Beats me.
dtech 9y ago
I think TDD works great if you have a very clearly designed input or interface. A programming language falls under this category: here's a piece of code, make sure it compiles and returns the correct output is a perfect test. And one which you can defined beforehand and is achievable to write as a test. However, programmers are often not in such a luxurious position. Business requirements are unclear, it is unclear what the solution even should look like, and the requirements will change over time and are changed based on the software's progress. In this case TDD only slows you down. It's also why short iteration times (i.e. agile) seem work relatively well in software development.
- s73ver 9y ago
  If the requirements are unclear, then why are you writing code? Why aren't you having conversations with people to clear up those requirements?
  - dtech 9y ago
    Because there is only so much talking is going to do, at some point you just need to build a prototype and see if it works and how it can be improved. If pre-planning, talking and requirements solved this problem we wouldn't see failed (software) projects and companies. As a matter of fact, extensive requirement gathering before prototyping and iterating is a good way to fail a project as at some point you're just adding new towers to your castle in the air.
    - s73ver 9y ago
      Yeah, but if you're prototyping, then that shouldn't be the actual code you use. You write a prototype to test your assumptions, have the people bang on it for a bit, then throw it away. You take the lessons you've learned from that, and now you have more of a "spec" than you did before. Thus, you can write your tests.
- lgunsch 9y ago
  It's exactly the opposite. TDD was a put forward as a solution to unclear, changing business requirements. It allows you to adjust course very quickly when the business realizes its requirements were off and new set of requirements are needed. Robert Martin has even mentioned that it's a waste of time if you have a full 100% specification available to you, or when you already know what the final solution is and simply need to implement it.
slaymaker1907 9y ago
Manual testing should be avoided when possible, but sometimes it is absolutely necessary.

maxxxxx 9y ago

I also don't understand why people tend to elevate a technique that's very useful for some cases to a religion that needs to be followed always.

sqeaky 9y ago
People have a constrained view. They see their own problems and have seen the "old" way do nothing but fail and the "new" way do nothing but succeed. What other reaction would you expect? If they actively researched and looked beyond their personal experience then dramatic 0% to 100% Success rates would turn into more reasonable assessments. I think my view on TDD is more reasonable than most of the zealots, but I still like mant of the ideas of TDD a great deal. I don't think it much matters if the tests come before or after the code as long as they come early enough to save time and effort. This means that specification of some kind is required, without specification you can't do TDD. Once you have tests and some code, you can add more test to increase confidence and with confidence you can aggressively refactor. Sometimes its enough to write a minimal viable product and then write tests just so that refactoring for version 2 can be done reliably. I am doing something like this now for some C++ build system stuff... That sounds odd saying it loud, but yes I have cmake modules complex to need tests so I can be confident in refactoring them. But I didn't write any tests until the minimal viable version sort of work enough to have bugs filed against it. Now TDD on ethat project seems like great idea, when I didn't use any tests in the beginning (Partly because we couldn't specify what we wanted).
- maxxxxx 9y ago
  " have seen the "old" way do nothing but fail and the "new" way do nothing but succeed." When I look at TDD I see a lot of success but also a lot of fail once people start pushing it too far. To me a fail is when the mock becomes more complex than the real system or a system can't be refactored because the refactoring of the tests takes too long or the tests are just so complex nobody wants to touch them. This reminds me a little of the situation with OOP. It solved a lot of real problems but then people said "only objects" and you ended up with stuff like replacing a simple switch statement and 100 easy to read lines of code with command patterns that had the implementation spread out over 10 different files.
  - sqeaky 9y ago
    I think you are totally correct both in your view that some take goods things too far and that this isn't the first time this pattern has been repeated. I wonder what things I am expounding now that I will pull back on in the future?

comstock 9y ago

It's interesting to me that programming is becoming a fundamental part of many (maybe most) things humans do. And yet we treat it as if there was one single correct way of programming and all other ways are wrong. I feel like it's much more akin to human language. Though the language primatives might be the same, it's used differently in different contexts are appropriate. In formal, legal speech, you might want to be explicit. In informal, everyday speech, not so much. Similar analogs exist in programming. 10 time script to reformat data for one time use, careful documentation, tests etc. not really required. Aircraft flight control system, very different... But then why is it that so many programmers seem to focus on "the one true way" (TDD, agile etc). Beats me.

dtech 9y ago

I think TDD works great if you have a very clearly designed input or interface. A programming language falls under this category: here's a piece of code, make sure it compiles and returns the correct output is a perfect test. And one which you can defined beforehand and is achievable to write as a test. However, programmers are often not in such a luxurious position. Business requirements are unclear, it is unclear what the solution even should look like, and the requirements will change over time and are changed based on the software's progress. In this case TDD only slows you down. It's also why short iteration times (i.e. agile) seem work relatively well in software development.

s73ver 9y ago
If the requirements are unclear, then why are you writing code? Why aren't you having conversations with people to clear up those requirements?
- dtech 9y ago
  Because there is only so much talking is going to do, at some point you just need to build a prototype and see if it works and how it can be improved. If pre-planning, talking and requirements solved this problem we wouldn't see failed (software) projects and companies. As a matter of fact, extensive requirement gathering before prototyping and iterating is a good way to fail a project as at some point you're just adding new towers to your castle in the air.
  - s73ver 9y ago
    Yeah, but if you're prototyping, then that shouldn't be the actual code you use. You write a prototype to test your assumptions, have the people bang on it for a bit, then throw it away. You take the lessons you've learned from that, and now you have more of a "spec" than you did before. Thus, you can write your tests.
lgunsch 9y ago
It's exactly the opposite. TDD was a put forward as a solution to unclear, changing business requirements. It allows you to adjust course very quickly when the business realizes its requirements were off and new set of requirements are needed. Robert Martin has even mentioned that it's a waste of time if you have a full 100% specification available to you, or when you already know what the final solution is and simply need to implement it.

slaymaker1907 9y ago

Manual testing should be avoided when possible, but sometimes it is absolutely necessary.