4 ms·

> TDD won't help you solve problems that you don't already know how to solve So, those Sudoku testing article fails because the author is breaking rules of TDD

> TDD won't help you solve problems that you don't already know how to solve So, those Sudoku testing article fails because the author is breaking rules of TDD. I mean, the first test: test_cells, does so much more than it needs to do to pass the test. He's designing first, and then testing. That's not how TDD works. If you can't see why that first test is a bad test, you aren't qualified to judge the merits of TDD. > Of course somebody is going to chip in here and say … you should be testing at the point where you can create a stable API that remains unchanged That's not true. At least, not the way you phrase it. You are, of course, forgetting that TDD involves 3 steps. Writing a test, Passing that test, and then refactoring. That refactoring includes refactoring the test. API's can, and should change to evolve. That's part of refactoring. You pretty much repeat the same arguments against TDD that I see time and time again. Arguments born out of misunderstandings. TDD isn't easy. It's challenging, it requires practice and effort. It does take time. > TDD forces you to decide about one of the hardest parts of development (API design / where to place abstraction boundaries) up front before you have worked out how to solve the problem at all. Yes, but nothing about TDD prevents you from easily making changes as needed. Again, Refactoring is apart of TDD. You say something like this multiple times, making it seem like refactoring or changing code is some painful process. It's not. It's trivial. If it's not, your process has a serious problem.

lifeisstillgood 13y ago
> That's not how TDD works if you are looking at Ron Jeffries Doyen of the Agile set, and saying "well of course he did not get the results, he was doing it wrong" the we are well into id-protecting, religious territory. if one of the leading exponents gets the process wrong there is something wrong with applying the process to the real world TDD really seems to me to be two parts: - Design up front, disguised as writing an API - Ensuring you write repeatable tests before commuting
- dragandj 13y ago
  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
- dragonwriter 13y ago
  > if one of the leading exponents gets the process wrong there is something wrong with applying the process to the real world I'm more interested in extracting what works from a concept than slavishly following a cult leader. IME, being a "leading exponent [sic]" of anything doesn't make you infallible, even in that domain. > Design up front, disguised as writing an API The TDD literature I am familiar with doesn't advocate writing an API up front, it recommends writing essentially a minimal fact statement up front about the API, writing tests to verify that fact statement, writing code to pass that test if it doesn't already pass with the existing code base, and iterating like that. You could design more than the single fact that you make the test and code for at one time, but that's not a demand of TDD or even relevant to it, and is not, in most cases, consistent with the kind of decide-as-late-as-possible rule that the Agile and Lean approaches in which TDD is usually embedded prefer. I suppose it would make some sense if you were doing waterfall-adapted-to-incorporate-TDD, but why on earth would you do that?
  - jasonlotito 13y ago
    Anyone who talks about TDD as "two parts" doesn't know TDD. Wouldn't worry about it.
- jasonlotito 13y ago
  He was wrong. There's nothing about it. Are you really going to sit their and say that he couldn't have been wrong? That he's perfect? That he can't have made a mistake. The first test in that blog post was a bad test to start with. It's as simple as that. I'm sorry, but appealing to authority isn't going to work here. He was wrong.

lifeisstillgood 13y ago

> That's not how TDD works if you are looking at Ron Jeffries Doyen of the Agile set, and saying "well of course he did not get the results, he was doing it wrong" the we are well into id-protecting, religious territory. if one of the leading exponents gets the process wrong there is something wrong with applying the process to the real world TDD really seems to me to be two parts: - Design up front, disguised as writing an API - Ensuring you write repeatable tests before commuting

dragandj 13y ago
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
dragonwriter 13y ago
> if one of the leading exponents gets the process wrong there is something wrong with applying the process to the real world I'm more interested in extracting what works from a concept than slavishly following a cult leader. IME, being a "leading exponent [sic]" of anything doesn't make you infallible, even in that domain. > Design up front, disguised as writing an API The TDD literature I am familiar with doesn't advocate writing an API up front, it recommends writing essentially a minimal fact statement up front about the API, writing tests to verify that fact statement, writing code to pass that test if it doesn't already pass with the existing code base, and iterating like that. You could design more than the single fact that you make the test and code for at one time, but that's not a demand of TDD or even relevant to it, and is not, in most cases, consistent with the kind of decide-as-late-as-possible rule that the Agile and Lean approaches in which TDD is usually embedded prefer. I suppose it would make some sense if you were doing waterfall-adapted-to-incorporate-TDD, but why on earth would you do that?
- jasonlotito 13y ago
  Anyone who talks about TDD as "two parts" doesn't know TDD. Wouldn't worry about it.
jasonlotito 13y ago
He was wrong. There's nothing about it. Are you really going to sit their and say that he couldn't have been wrong? That he's perfect? That he can't have made a mistake. The first test in that blog post was a bad test to start with. It's as simple as that. I'm sorry, but appealing to authority isn't going to work here. He was wrong.