Timeline for Cheap implementations in fundamental TDD
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 20, 2015 at 11:43 | comment | added | Marjan Venema | @alfe instead of expanding an existing test case, you can always add an extra one. Each test should cover just one aspect of a function/method. Doesn't mean there can only be one assert (it often takes more than one assert to verify an aspect); but your second scenario should probably have its own test method within the testclass instead of being added to the first. | |
| Feb 9, 2015 at 16:11 | comment | added | Alfe | The TC is certainly not buggy. One might call it incomplete, allright, but that's a matter of taste, more or less, lacking a clear definition of when it would be complete. Coverage in TDD should always be at 100% (if done correctly), so expanding the TC before the implementation if shall test is there would not change the coverage. | |
| Feb 9, 2015 at 16:05 | comment | added | Dan Pichelman | @Alfe If the TC is buggy or obviously incomplete, wouldn't it make sense to correct the oversight? (In this case, expanding test coverage - contracting it would be a different matter). | |
| Feb 9, 2015 at 15:59 | comment | added | Alfe | What about the notion that by being allowed to change the TC the developer could even more easily make the TC green, namely by taking aspects out of the TC? This could happen without intention of course (I'm not talking about cheaters but about hasty situations). Do you really think it is a good idea to allow adjustments to the TC? Is that still the fundamental(istic) way of TDD? | |
| Feb 9, 2015 at 15:56 | history | answered | Dan Pichelman | CC BY-SA 3.0 |