Why are these called test categories, they feel more like design categories. I know with test first I should think of test before design, but the word test has a strong QA connotation that makes my brain think of it as something that is done in the end. It is more natural to think of these as design categories (now I may use test first as a smell driven forcing function to drive towards these) but the categories are still for design (and btw a great way to think about it).
You should have an option on your blog so that the text "test" can be replaced with "specification" dynamically... so I can read this from part 1: "thus we have to know what the customer wants before we can create the [test]" and then flip a switch and read this instead: "thus we have to know what the customer wants before we can create the [specification]"... maybe one article with this trick so people can used to thinking test=specification (note use assignment operator :-)
You make a fair point. The word "test" has proven misleading in TDD, and in a sense one could say we should simply stop using it. However, there are two things to keep in mind: 1) TDD is a well-established term in our industry, and if we don't use it, then people will not connect what we are talking about with what they are doing, or wish to do, or wish to do better. 2) While we do not write these things to be tests, they do become tests after we are done developing the code (we retain them as tests against regression). So, calling them tests helps to reinforce that TDD produces multiple values for a single effort.
As to the idea of the dynamic word-switching, I think it's a cool thought. The only problem is that we are ultimately writing all this for publication in a book, where such dynamic behavior is obviously not possible. I like the idea, though... maybe there is something else we can do with it. :)
Why are these called test categories, they feel more like design categories. I know with test first I should think of test before design, but the word test has a strong QA connotation that makes my brain think of it as something that is done in the end. It is more natural to think of these as design categories (now I may use test first as a smell driven forcing function to drive towards these) but the categories are still for design (and btw a great way to think about it).
ReplyDeleteYou should have an option on your blog so that the text "test" can be replaced with "specification" dynamically... so I can read this from part 1: "thus we have to know what the customer wants before we can create the [test]" and then flip a switch and read this instead: "thus we have to know what the customer wants before we can create the [specification]"... maybe one article with this trick so people can used to thinking test=specification (note use assignment operator :-)
ReplyDeleteYou make a fair point. The word "test" has proven misleading in TDD, and in a sense one could say we should simply stop using it. However, there are two things to keep in mind: 1) TDD is a well-established term in our industry, and if we don't use it, then people will not connect what we are talking about with what they are doing, or wish to do, or wish to do better. 2) While we do not write these things to be tests, they do become tests after we are done developing the code (we retain them as tests against regression). So, calling them tests helps to reinforce that TDD produces multiple values for a single effort.
ReplyDeleteAs to the idea of the dynamic word-switching, I think it's a cool thought. The only problem is that we are ultimately writing all this for publication in a book, where such dynamic behavior is obviously not possible. I like the idea, though... maybe there is something else we can do with it. :)
ReplyDelete