4 ms·

I didn't check with the literature, but in my opinion, the biggest misunderstanding of TDD is that lots of people take it to mean literary Test-First Design. As

I didn't check with the literature, but in my opinion, the biggest misunderstanding of TDD is that lots of people take it to mean literary Test-First Design. As I understanding, in Test-DRIVEN-Design, you are writing the implementation code in PARALLEL to testing code. You write a tiny bit of test, then a tiny bit of implementation to satisfy the test. If you notice something you'd missed previously, you refactor BOTH tests and implementation. You repeat and expand a bit...

recursive 13y ago
If you didn't check the literature and have your own understanding of what TDD is, then it should be no surprise that what you are talking about is different from what everyone else is talking about.
- mkolodny 13y ago
  She/he is talking about exactly what everyone else is talking about. That's TDD. "Didn't check the literature" may have meant that the reply didn't come after reading the referenced book.
- jasonlotito 13y ago
  This is what the parent said: > You write a tiny bit of test, then a tiny bit of implementation to satisfy the test. If you notice something you'd missed previously, you refactor BOTH tests and implementation. That's TDD. He was alluding to the fact that people might assume that they have to write all the tests first.
RogerL 13y ago
Read the literature. Kent Beck, the author of the idea and the book describing it, very clearly argues for test first. The test tells you how to design. I'm not sure if that is what you mean by your paragraph or not. But in his book, the test is always written first, and it guides you into how you should write your code. I found it extremely dubious. He was doing some kind of accounting/banking app, and came up with a new approach. Well, he spent his career on this domain. I find it far less likely that TDD caused the new idea than it was just that he'd hoed this row so many times before. If you have done it 10 times before you can do bottom up, top down, inside out, outside in, or completely random, and get a reasonably structured, working code base. I conclude nothing by him creating accounting app #11 with a scheme that is perhaps well suited to how his brain works, but is perhaps terrible for mine. I'm not against testing, quite the contrary, but I find some of the claims rather exuberant.
- jasonlotito 13y ago
  > Read the literature. Kent Beck, the author of the idea and the book describing it, very clearly argues for test first. No, you are misunderstanding the parent. He meant some people assume you write _all_ tests first. If you read his entire comment, you'll see how he describes exactly the process described by Kent Beck. A small test, a small implementation, followed by refactoring both test and implementation (the 3rd part being the part commonly forgotten).
jasonlotito 13y ago
> You write a tiny bit of test, then a tiny bit of implementation to satisfy the test. If you notice something you'd missed previously, you refactor BOTH tests and implementation. Bingo! Exactly that. Right on the money, especially the part about refactoring both tests and implementation.

recursive 13y ago

If you didn't check the literature and have your own understanding of what TDD is, then it should be no surprise that what you are talking about is different from what everyone else is talking about.

mkolodny 13y ago
She/he is talking about exactly what everyone else is talking about. That's TDD. "Didn't check the literature" may have meant that the reply didn't come after reading the referenced book.
jasonlotito 13y ago
This is what the parent said: > You write a tiny bit of test, then a tiny bit of implementation to satisfy the test. If you notice something you'd missed previously, you refactor BOTH tests and implementation. That's TDD. He was alluding to the fact that people might assume that they have to write all the tests first.

RogerL 13y ago

Read the literature. Kent Beck, the author of the idea and the book describing it, very clearly argues for test first. The test tells you how to design. I'm not sure if that is what you mean by your paragraph or not. But in his book, the test is always written first, and it guides you into how you should write your code. I found it extremely dubious. He was doing some kind of accounting/banking app, and came up with a new approach. Well, he spent his career on this domain. I find it far less likely that TDD caused the new idea than it was just that he'd hoed this row so many times before. If you have done it 10 times before you can do bottom up, top down, inside out, outside in, or completely random, and get a reasonably structured, working code base. I conclude nothing by him creating accounting app #11 with a scheme that is perhaps well suited to how his brain works, but is perhaps terrible for mine. I'm not against testing, quite the contrary, but I find some of the claims rather exuberant.

jasonlotito 13y ago
> Read the literature. Kent Beck, the author of the idea and the book describing it, very clearly argues for test first. No, you are misunderstanding the parent. He meant some people assume you write _all_ tests first. If you read his entire comment, you'll see how he describes exactly the process described by Kent Beck. A small test, a small implementation, followed by refactoring both test and implementation (the 3rd part being the part commonly forgotten).

jasonlotito 13y ago

> You write a tiny bit of test, then a tiny bit of implementation to satisfy the test. If you notice something you'd missed previously, you refactor BOTH tests and implementation. Bingo! Exactly that. Right on the money, especially the part about refactoring both tests and implementation.