Timeline for TDD negative experience
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 28, 2011 at 15:55 | history | made wiki | Post Made Community Wiki by Cesar Canassa | ||
| Aug 5, 2011 at 0:10 | comment | added | user1249 | @aaronaught, then write some of those. | |
| Aug 4, 2011 at 20:19 | comment | added | user1249 | @Danious, I've reworded this as you are correct in stating that this is not about writing an API but focusing on how to actually verify that the code returns a certain output given a certain input. I consider that quite an important part of solving a problem. | |
| Aug 4, 2011 at 20:17 | history | edited | user1249 | CC BY-SA 3.0 | rewriting API to generic "how to call" |
| Aug 4, 2011 at 15:29 | comment | added | Dainius | your first sentence about API focusing is why anyone should avoid this kind of development process, because your goal is to solve problems not write a good looking api. | |
| Aug 4, 2011 at 15:09 | comment | added | Aaronaught | Answers should address the question. | |
| Aug 4, 2011 at 15:05 | comment | added | user1249 | @aaronaught, I am addressing his pain points. | |
| Aug 4, 2011 at 13:18 | comment | added | Aaronaught | The question was not asking about the benefits of TDD. There are already plenty of other questions on that. | |
| Aug 4, 2011 at 12:34 | comment | added | Steven Jeuris | Benefit point 2 can be achieved with simple unit tests without a TDD approach as well. Benefit 1 you should be doing anyhow. (Focusing on the API) It's still entirely possible to create a crappy API using TDD, but yes, you are guaranteed that it will work (for the written tests). | |
| Aug 4, 2011 at 9:36 | history | answered | user1249 | CC BY-SA 3.0 |