Timeline for Why is agile all about the test-driven development (TDD) and not development-driven test (DDT)?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 3, 2016 at 18:02 | comment | added | svidgen | @nerdlyist Integration and regression tests can be done test-first too. Doing so doesn't quite fit the "TDD dogmatists" development cycle, but the result is largely the same: You end up with testable code, with minimal extraneous code, and tests that actually validate what they claim to. Testing after you write the code can make accomplishing any or all of those those things a bit harder. Not at all impossible, but potentially more difficult. | |
| Aug 3, 2016 at 17:24 | comment | added | nerdlyist | @kai This was for sure one thing I was over exaggerating in my head. Since door could be a super class and have many children then there really is no waste in writing the unit. It will always be used. Even if the glass door is not used right now it maybe down the road and good thing that intern has the old tests for it.There is defiantly nothing to burn down. | |
| Aug 3, 2016 at 17:15 | comment | added | sara | @nerdlyist a good design is modular. if you realize that "whoops, we can't have a wooden door, we need a solid steel one!", then you don't change a whole bunch of things. you don't burn down your wooden door. you don't slowly rework the wooden door into a steel one. you build a steel door and you "unplug" the wooden one and "plugin" the steel one. "good TDD" (yeahyeah no true scotsman, sue me) prevents you from making changes that violate the specification you have created for a single unit. in this case, you MUST change things, or create something new. not a TDD issue. | |
| Aug 3, 2016 at 16:53 | comment | added | nerdlyist | If I could +1 again I would that last bit is helpful to consider. Not everything needs a test. Also, rereading it made me think maybe I am fusing TDD unit tests with integration and regression testing. The workers automatically testing is units the inspector is integration and regression testing is done when making larger changes. | |
| Aug 3, 2016 at 16:32 | comment | added | svidgen | @nerdlyist Please see me edits too. I think I overlooked a core aspect of your question. | |
| Aug 3, 2016 at 16:32 | history | edited | svidgen | CC BY-SA 3.0 | added 540 characters in body |
| Aug 3, 2016 at 16:31 | comment | added | nerdlyist | As I start to come around now it would also seem that the door could be a parent and then child classes would need there own. One could be the sliding glass door. This make a lot more sense now. | |
| Aug 3, 2016 at 16:31 | history | edited | svidgen | CC BY-SA 3.0 | added 540 characters in body |
| Aug 3, 2016 at 16:21 | comment | added | svidgen | Going back to the house analogy: If your client suddenly wants to swap in a different style of door, and it doesn't have the same dimensions, requirements around the door and opening dimensions will change, and the work require to change those "tests" should mirror the work required to make the implementation change. But, there are a lot of tests that won't change: The door must open and close, lock, and be P% airtight in the opening when closed, etc... Lots of tests that don't change that "hinder" physical changes appropriately. | |
| Aug 3, 2016 at 16:14 | comment | added | svidgen | @nerdlyist In a way, yes. But, if your tests are checking the "right" things, it's a "hinderance" you want. | |
| Aug 3, 2016 at 16:10 | comment | added | nerdlyist | I get code != physical its an analogy. But this actually clears up a little more for me. As my other comment point out I am wondering if this create the test first hinders the desire to go back and make larger changes now? | |
| Aug 3, 2016 at 15:55 | history | edited | svidgen | CC BY-SA 3.0 | deleted 16 characters in body |
| Aug 3, 2016 at 15:22 | history | edited | svidgen | CC BY-SA 3.0 | added 42 characters in body |
| Aug 3, 2016 at 15:16 | history | answered | svidgen | CC BY-SA 3.0 |