3 ms·

Here is my preferred and almost too simple workflow: Think about the feature Write the feature Test the feature (RSpec and Capybara) Deploy wit

Here is my preferred and almost too simple workflow: Think about the feature Write the feature Test the feature (RSpec and Capybara) Deploy with acceptable level of confidence The testing part is in #3 exactly where it belongs. It's my understanding that a major (perhaps the major) benefit of test-driven development is not that the tests are actually useful or speed up the writing of the code, but that the process of writing tests forces you to do some high-level design and specify how your code will work before you start clacking away. Seen this way, even if your tests are thrown out or never run after they are created, writing them was still a good idea because it resulted in your final product being better designed.

user_0001 11y ago
Or skip the test and just think about it before. We do not need to be "tricked" into thinking about / creating better designs
- riffraff 11y ago
  There is ample literature pointing out that yes, we do need to be tricked into doing it, or we might not do it. There is also a lot showing that "just thinking about it before" often leads to useless abstractions and complications, while doing TDD properly leads to an appropriate level. YAGNI, KISS and all that. I mean, this is all arguable, and has been since XP boomed in the late early 2000s, but it's disingenuous to ignore it.
phamilton 11y ago
Another example is TDD for fixing bugs. Reproduce the bug Capture reproduction steps in a test Fix the bug Deploy It's a similar process. If you are going through all the effort of reproducing the test, you might as well automate it. If you are going through all the effort of design, you might as well capture it programmatically. That said, I have two main principles I follow: 1) Black box test at the interface level. 2) Be willing to delete tests if they become bothersome.

user_0001 11y ago

Or skip the test and just think about it before. We do not need to be "tricked" into thinking about / creating better designs

riffraff 11y ago
There is ample literature pointing out that yes, we do need to be tricked into doing it, or we might not do it. There is also a lot showing that "just thinking about it before" often leads to useless abstractions and complications, while doing TDD properly leads to an appropriate level. YAGNI, KISS and all that. I mean, this is all arguable, and has been since XP boomed in the late early 2000s, but it's disingenuous to ignore it.

phamilton 11y ago

Another example is TDD for fixing bugs. Reproduce the bug Capture reproduction steps in a test Fix the bug Deploy It's a similar process. If you are going through all the effort of reproducing the test, you might as well automate it. If you are going through all the effort of design, you might as well capture it programmatically. That said, I have two main principles I follow: 1) Black box test at the interface level. 2) Be willing to delete tests if they become bothersome.