Timeline for A weakness of the TDD method?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 14, 2014 at 20:32 | comment | added | Giorgio | What is not clear to me yet is how a square root algorithm should emerge incrementally by adding tests one at a time: no matter how many special cases you test, in order to implement the final algorithm you have to analyse the problem and solve it. IMO TDD does not help much in this case. | |
| May 13, 2013 at 21:11 | comment | added | Doc Brown | @Belin: requirement analysis is not a TDD activity, it is done separately and before you code (but it is up to you if you try to do all analysis beforehand or only for one requirement at a time). Design is something the TDD evangelists claim the test-first approach contains somehow - but IMHO TDD will primarily improve your program's testability, not less, not more. Most other design aspects are not in the focus of TDD - as a good designer you will (still) have to think about a problem, find a solution, and then start coding (TDD style, if you like). | |
| May 8, 2013 at 7:08 | comment | added | Belin | In the TDD methodology, when you made the analysis and design of your program? in the example given the design of the square root algorithm is done before writing tests? after? thank you | |
| May 7, 2013 at 16:45 | answer | added | Carl Manaster | timeline score: 14 | |
| May 7, 2013 at 15:56 | history | edited | user40980 | CC BY-SA 3.0 |
Minor fixes. Code format, caps, '4', etc...
|
| May 7, 2013 at 13:36 | comment | added | David Hall | @Belin Spoike has said what I would have - you should only be writing one test at a time. These tests can come from various places - the spec, known bugs or limitations in the current code, or known parts of the implementation that need testing (for example if you introduce an if statement, you know you need to test both branches). As you add these new tests you will often break (and then fix) earlier tests - this is part of the methodology. Of course TDD is also a pragmatic methodology, so these rules are often breakable, but when learning the approach it is advised to follow them closely. | |
| May 7, 2013 at 13:31 | comment | added | Doc Brown | @Belin: it is a common misbelieve that TDD is a "black-box" approach - writing tests without looking into the implementation, only into the spec. That is a fallacy - TDD is indeed a white-box method - you write tests for what your current implementation is missing. | |
| May 7, 2013 at 13:12 | comment | added | Spoike | @Belin: You are supposed to add ONE test (preferably with at most one assertion), write code to make that ONE test pass, and continue on with the next ONE test. | |
| May 7, 2013 at 12:57 | comment | added | Belin | "Do the simplest possible thing to make the test pass" in my example, when to add the case where number is lower than 1? when to add the test for that case? | |
| May 7, 2013 at 12:29 | comment | added | JeffO | You're lucky the specification included handling the negative number. Do you think every database app spec address NULL? | |
| May 7, 2013 at 12:15 | answer | added | Winston Ewert | timeline score: 20 | |
| May 7, 2013 at 12:10 | review | Close votes | |||
| May 7, 2013 at 16:09 | |||||
| May 7, 2013 at 12:06 | comment | added | David Hall | What you have described is for many reasons not TDD. Two most obvious are that rather than writing a test, you have started with three, and that you have missed the "Do the simplest possible thing to make the test pass" step and replaced it with "write production code" which is not at all TDD. You have jumped directly to an implementation. By jumping to an implementation your tests will tend to be more tightly coupled to that implementation. | |
| May 7, 2013 at 12:00 | review | First posts | |||
| May 7, 2013 at 12:35 | |||||
| May 7, 2013 at 11:53 | comment | added | gnat | possible duplicate of Are "TDD Tests" different to Unit Tests? See also: What are the disadvantages of test-first programming? and Is unit testing or test-driven development worthwhile? | |
| May 7, 2013 at 11:44 | history | asked | Belin | CC BY-SA 3.0 |