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
32 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 25, 2016 at 3:34 | audit | First posts | |||
| Aug 25, 2016 at 3:36 | |||||
| Aug 9, 2016 at 7:17 | comment | added | Phil Riley | The emergent design I was referring to does come, but I agree you do need someone steering it. This is again where pair programming comes in; you might have one half of the pair an "experienced" coder, the other a "junior", and in that case the experienced coder can drive the design as well. | |
| Aug 7, 2016 at 19:37 | comment | added | Cubic | @Mehrdad I certainly wouldn't force a programmer to write code in a certain order. You're right, if the commit is the same it doesn't matter. However, if you only write code for things which you have tests for you'll never produce commits which lack tests (tautologically). I think it's a bit easier to stay disciplined about the order of something (first test, then implement) than about causality (I implemented something, now I have to write a test for it). | |
| Aug 7, 2016 at 19:33 | comment | added | user541686 | @Cubic: Of course not? I wouldn't even be able to tell when they wrote it, all I can expect is for them to commit them together. So my point is there's no reason for them to do it before the functionality is implemented rather than after; I wouldn't even be able to tell. | |
| Aug 7, 2016 at 19:30 | comment | added | Cubic | @Mehrdad If you're disciplined enough, yes. In your model, would you pass code that doesn't have tests yet through review if the author promises they're going to write the tests later? | |
| Aug 7, 2016 at 19:28 | comment | added | user541686 | @Cubic: I agree that's useful but I don't understand what that has to do with my question? I wasn't asking about not having tests at all, I was asking about writing each one after you've implemented the feature rather than before. That'd still be true regardless, right? 'cause you already know that 1 new test is failing, and the previous tests already exist there. | |
| Aug 7, 2016 at 19:24 | comment | added | Cubic | @Mehrdad The point is that you always have tests covering most of your code so you can change things and have a quick way to figure out if your changes broke something, and if they did, what. | |
| Aug 6, 2016 at 7:54 | comment | added | user541686 | @BartvanNierop: Hm, I see. So if it's about quick feedback, then it's just a speed thing? What if I don't particularly have anything pressing me to be coding as fast as possible? Would I not care then? | |
| Aug 5, 2016 at 9:48 | comment | added | Bart van Nierop | @Mehrdad The goal is quick feedback. And not only on correctness. That's just a bonus that shouldn't be relied on, because you're bound to miss cases. Writing your test first gives you quick design feedback. You write the test without the code implementing it actually existing, so you can write your interface by wishful thinking. Then write the implementation. If the test is difficult to write, your design is probably flawed. Now, you could get this feedback if you wrote the test after instead of before... But that would be after implementing one (or many) things that need rethinking. | |
| Aug 4, 2016 at 22:48 | comment | added | user541686 | @Davor: what I'm saying is, what's the point of writing a test that you keep changing at will? Changing the test is extra work that you could completely avoid by simply writing the test once at the end. And the whole point of this example was to show that the actual implementation affects the usage and hence the tests. | |
| Aug 4, 2016 at 22:22 | comment | added | Davor Ždralo | @Mehrdad - why in the world do you think that tests are set in stone? They change as you code. And also, why are you testing the implementation? TDD should be black box testing. You call a method, give it arguments, and check the solution. How the method does it's thing internally SHOULD NOT be taken into account. You're testing the method contract, not internal implementation. | |
| Aug 4, 2016 at 17:50 | comment | added | user541686 | I still don't understand. The only difference between writing the test beforehand and writing it afterward is that you're making your design inflexible by writing it beforehand. Example, your test might say x == y, but then after you write the code to make the test pass you might realize that's actually prohibitively expensive, and you should really have been testing entire vectors for equality (e.g. all(x[:] == y[:])). Now how the hell did it help you to set the design in stone in the first place? Why not make the system and then write a test that actually makes sense for it? | |
| Aug 4, 2016 at 9:13 | comment | added | Jonathan. | But even if you don't write all the tests at the start, how do you you are writing what you need? You might right some tests for a class that specify how it behaves, but then later on realise actually this was the completely wrong way to approach the problem, so the class needs to be changed considerably. | |
| Aug 3, 2016 at 17:49 | comment | added | svidgen | @nerdlyist Emergent design is the notion that you can change your architecture and add modules on-the-fly as-needed. It's the idea that you don't need detailed specifications for each module or interaction up-front. But, the emergent design proponents often fail to acknowledge that the details aren't usually needed up-front b/c practitioners of emergent design already know the details ... | |
| Aug 3, 2016 at 17:47 | comment | added | svidgen | @DavidArno I think your objection stems from not giving yourself enough credit as an experienced developer/architect. Because you already know what module X looks like intuitively, your tests will be driving your development in a good direction. An inexperienced developer with few to no intuitive notion of what a module should look like before writing the tests will build a well-tested, crappy module. | |
| Aug 3, 2016 at 17:32 | comment | added | JimmyJames | @nerdlyist Sorry, I'm not sure which comment you are referring to but the first one was about using TDD. I find it somewhat tedious but I do think it can result in higher quality code. Unit tests in general are really helpful on multi-person projects because they help you avoid breaking other people's stuff. | |
| Aug 3, 2016 at 17:27 | comment | added | nerdlyist | @JimmyJames If I could add an emoji it would be my head exploding. Thanks for this bit of information. I was super focused on TDD and let this one slid by. | |
| Aug 3, 2016 at 17:26 | comment | added | David Arno | @RobertHarvey, I might start with a set of requirements, but those requirements are often fluid. And I actively resist silly requirements like "must use SQL Server" for example. The thing is "there's nothing at all magical about writing your tests first, other than it forces you to make your code more testable" is the killer feature of writing automated tests as you go. Easily testable code has to be loosely coupled. If suddenly the customer wants to use a no-sql DB, then only the data access layer need be swapped out. So the "architecture" isn't so important. | |
| Aug 3, 2016 at 17:19 | comment | added | JimmyJames | @nerdlyist start here: en.wikipedia.org/wiki/… | |
| Aug 3, 2016 at 17:14 | comment | added | nerdlyist | @RobertHarvey would you mind to explain was Emergent Design? | |
| Aug 3, 2016 at 17:08 | comment | added | JimmyJames | @nerdlyist I don't want to get caught in the crossfire here but I wanted to mention that I was not 'raised' in this tradition but when I use it, I find that my first attempt to make my tests pass will often not work. I find issues earlier resulting in higher code quality at an earlier stage of development. | |
| Aug 3, 2016 at 17:02 | comment | added | Robert Harvey | @DavidArno: Do you begin with a requirements specification in hand? How do you translate that specification into a sensible architecture? Do you reinvent it each time with tests, or do you have previous architectural principles in mind? Nobody does this in the blind; there's nothing at all magical about writing your tests first, other than it forces you to make your code more testable. | |
| Aug 3, 2016 at 17:01 | comment | added | David Arno | @RobertHarvey, I completely disagree with your "The term "Emergent Design" makes it sound like you can grow a software design by making tests pass. You can't" statement. Having done just that on a number of occasions, I can assure you it can be done. | |
| Aug 3, 2016 at 16:45 | comment | added | nerdlyist | @RobertHarvey yes I do admit that was left out as a topic but in my example the "specs" would be a vetted design plan. Not to say that this does not continually change but my lack of understanding was mostly in the use of TDD not planning and design that make sense to me. | |
| Aug 3, 2016 at 16:36 | comment | added | Robert Harvey | @nerdlyist: Don't forget about design, though. You still need to design software; good design doesn't just naturally emerge from red-green-refactor. TDD encourages good design, but it doesn't create it. | |
| Aug 3, 2016 at 16:35 | comment | added | nerdlyist | All the other answers here were great and really help me understand this topic. I chose this one though because it helped me get past the biggest obstacle which was write everything up-front. This really shows how the iterations happen. | |
| Aug 3, 2016 at 16:35 | comment | added | Robert Harvey | The term "Emergent Design" makes it sound like you can grow a software design by making tests pass. You can't. | |
| Aug 3, 2016 at 16:29 | vote | accept | nerdlyist | ||
| Aug 3, 2016 at 16:23 | comment | added | nerdlyist | First thank you for not calling me outfor using a real world example. This was an eye opener. I think my biggest grip was because my professor had us commit tests first of everything we planned to do which seems wrong based on your depiction. | |
| Aug 3, 2016 at 16:21 | vote | accept | nerdlyist | ||
| Aug 3, 2016 at 16:21 | |||||
| Aug 3, 2016 at 16:00 | review | First posts | |||
| Aug 9, 2016 at 8:47 | |||||
| Aug 3, 2016 at 15:58 | history | answered | Phil Riley | CC BY-SA 3.0 |