4 ms·

Great book. I think a lot of people want to test, but lack skills. Testing software is actually quite difficult. You have to know what to test, then how. I

Great book. I think a lot of people want to test, but lack skills. Testing software is actually quite difficult. You have to know what to test, then how. I love tdd, but I find it takes too long for businesses to tolerate, so usually I have to test after to hit deadlines. Tdd works great for pure functions with logic. But things like ui integration tests (not to be confused with functional tests) are very time consuming to write with red green rafeactor tdd.

cjfd 7y ago
I am not sure TDD really takes that much longer. Writing the tests certainly takes time but if you don't write tests you will have to spend more time testing the software manually. If the test is a sequence of 20 click in a web interface and you have to do that multiple times before it works that also costs time and you are probably not going through every scenario in that case so errors can remain undiscovered for some time. I don't always do TDD in a 100% strict way. The duration of the TDD cycle varies for me mainly depending on how practical a very short cycle is and also depending on how complex the software is. I have found that overly obsessing about very short cycles can be inefficient. Also, I tend to test a cluster of multiple classes instead of a single class or a single method. I think the subject that a test is about should be something at a level that is a bit higher, perhaps even something that the customer could recognize as something they value. If you do not do that you might be testing implementation details that are very much subject to change. Testing at the right level also can save quite a bit of time. I don't write user interfaces that often and when I do they are mostly not that fancy. In that case I have sometimes written tests that check that the HTML output is correct. In the case of things that are purely visible I quite often first fix the thing and then write a test because the browser in my head is not always quite good enough to write a correct test beforehand. I have generally found that management was encouraging towards writing test in places where I have worked. Occasionally I have been praised for writing high quality software but also sometimes got the remark that sometimes things were taking a longer than expected. Everybody should be able to understand that there is a trade-off here. I would not want to work in a place where they produce as much crap as possible in as little time as possible. Lack of quality is quite hard on me emotionally.
- tus88 7y ago
  I think the problem with TDD is it assumes you know what shape your functions and classes and data structures will take before you start coding. This is rarely the case, and if it were easy then CASE tools would have won over the world in the 90s. They didn't and people still code in typeless scripting languages. I think it's this glossing over the inherent and deep complexity of software development that turns a lot of people off TDD. What's wrong with getting the software right, often through a process of trial and error, and then writing the tests to lock in what you have working?
  - cjfd 7y ago
    "TDD [...] assumes you know what shape your functions and classes and data structures will take before you start coding". Absolutely not. In a green field project you might start TDD with an 'architecture' consisting of only one function. Since one single function is a very bad architecture for anything except something extremely simple at some point refactoring would take that function into multiple functions, or make a class of it or do yet something else. The main difference with the CASE approach is that TDD does not presume that we can know an adequate architecture beforehand but instead can figure that out while we are going. I.e., decide things when we actually have the information to do it. TDD actually is the only method of software development that I know of that respects the complexities involved in software development. One might write test afterwards but as I note above tests do cost time so one should aim for the maximum payback of that time. When you start with the test it starts paying back as soon as possible starting from the point where it flags your first attempt making the test pass as not quite working. One case where it may be better to start with some trial and error is when it is not clear what algorithm should be used.
- davidjnelson 7y ago
  > In the case of things that are purely visible I quite often first fix the thing and then write a test because the browser in my head is not always quite good enough to write a correct test beforehand. This is what I was referring to.

cjfd 7y ago

I am not sure TDD really takes that much longer. Writing the tests certainly takes time but if you don't write tests you will have to spend more time testing the software manually. If the test is a sequence of 20 click in a web interface and you have to do that multiple times before it works that also costs time and you are probably not going through every scenario in that case so errors can remain undiscovered for some time. I don't always do TDD in a 100% strict way. The duration of the TDD cycle varies for me mainly depending on how practical a very short cycle is and also depending on how complex the software is. I have found that overly obsessing about very short cycles can be inefficient. Also, I tend to test a cluster of multiple classes instead of a single class or a single method. I think the subject that a test is about should be something at a level that is a bit higher, perhaps even something that the customer could recognize as something they value. If you do not do that you might be testing implementation details that are very much subject to change. Testing at the right level also can save quite a bit of time. I don't write user interfaces that often and when I do they are mostly not that fancy. In that case I have sometimes written tests that check that the HTML output is correct. In the case of things that are purely visible I quite often first fix the thing and then write a test because the browser in my head is not always quite good enough to write a correct test beforehand. I have generally found that management was encouraging towards writing test in places where I have worked. Occasionally I have been praised for writing high quality software but also sometimes got the remark that sometimes things were taking a longer than expected. Everybody should be able to understand that there is a trade-off here. I would not want to work in a place where they produce as much crap as possible in as little time as possible. Lack of quality is quite hard on me emotionally.

tus88 7y ago
I think the problem with TDD is it assumes you know what shape your functions and classes and data structures will take before you start coding. This is rarely the case, and if it were easy then CASE tools would have won over the world in the 90s. They didn't and people still code in typeless scripting languages. I think it's this glossing over the inherent and deep complexity of software development that turns a lot of people off TDD. What's wrong with getting the software right, often through a process of trial and error, and then writing the tests to lock in what you have working?
- cjfd 7y ago
  "TDD [...] assumes you know what shape your functions and classes and data structures will take before you start coding". Absolutely not. In a green field project you might start TDD with an 'architecture' consisting of only one function. Since one single function is a very bad architecture for anything except something extremely simple at some point refactoring would take that function into multiple functions, or make a class of it or do yet something else. The main difference with the CASE approach is that TDD does not presume that we can know an adequate architecture beforehand but instead can figure that out while we are going. I.e., decide things when we actually have the information to do it. TDD actually is the only method of software development that I know of that respects the complexities involved in software development. One might write test afterwards but as I note above tests do cost time so one should aim for the maximum payback of that time. When you start with the test it starts paying back as soon as possible starting from the point where it flags your first attempt making the test pass as not quite working. One case where it may be better to start with some trial and error is when it is not clear what algorithm should be used.
davidjnelson 7y ago
> In the case of things that are purely visible I quite often first fix the thing and then write a test because the browser in my head is not always quite good enough to write a correct test beforehand. This is what I was referring to.