4 ms·

I’ve been learning testing the last few months (been programming around a year) and this logic seems pretty apparent, and also fairly impossible to adhere to.

by gt_ 8y ago

I’ve been learning testing the last few months (been programming around a year) and this logic seems pretty apparent, and also fairly impossible to adhere to. More so, this idea of TDD seems a little ridiculous so far, and structural testing is why, but I wonder if this is just becuse I’m going through a period of wanting to refactor a lot while building something. TDD is clearly appropriate for adding features, but when architecting central components, I think it’s cost me a lot of time. Some of that time is writing and verifying extra tests but most of it is reviewing a mountain of tests each time I modify architecture. Is this just a learning phase? Or is there a long-term lesson to learn here?

eropple 8y ago
Testing basically breaks down into the following types (and you can flavor them however you want, but take this as a starting point): - test-last testing to test the implementation you just wrote - test-first testing to test the implementation you're gonna write - test-driven design, where the tests reflect the specification and are applied to the implementation So, with these on hand, here's my litmus test for TDD: Do I know what I'm building and why? You can't meaningfully do test-driven design if you don't know the what and the why. TDD tests need to encode "the business cares about this", and IME, the questions you are asking often arise when somebody doesn't really yet know what they're building. You're figuring it out. And that is okay, too! I'm not a TDD devotee (in that I would love to write code in a TDD fashion much more than I actually do, but I think it's probably the right answer for most situations where the unknowns have been solved or pushed out) and I think that you're describing a very common situation where writing tests while you're writing code, or maybe even after--though this is often fraught--is totally fine. I regularly build systems by writing tests to exercise bits and pieces of them in lieu of opening a REPL or running it through a command line; the Test Cops aren't gonna come get you if this works better during your exploratory phase. (It does mean your exploratory phase has some useful artifacts when it's done, though.) Put another way: if I have a spec, I can do TDD. If I don't, I can't, and I don't lose sleep over it.
- gt_ 8y ago
  Hilarious about the test cops. Testing seems to, so far, be a fairly wishy-washy task. The spec thing makes a lot of sense. The project I’m learning with is not ideal because the test environment takes a moment to boot but it’s peculiar and challenging me to consider real-world scenarios, which may or may not be a good thing but I’m near wrapping it up. It’s a plug-in for a few different content creation softwares. I would say I knew what I was building, but there have been unknowns about which particular approach will meet my standards and still be DRY. They all worked great with prototypes but I discovered some edge cases late in construction. I found TDD very satisfying but now I have an instinctual doubt about it. Your thoughts make a lot of sense. I guess one of the main things will do next time is avoid all the extra unit testing I did early on. I think I was honestly having too much fun. Someone should do research on if automated test coverage illicits the slot-machine effect.
- swish_bob 8y ago
  If you don't know what you're doing, how can you do it? I don't see how this is a TDD thing or not ...
  - eropple 8y ago
    You've never written exploratory code before?
MiyamotoAkira 8y ago
The same that that structural test creates unnecessary coupling there will be other tests that create that coupling as well. It is a learning phase. You will realize that there are things that you can do and things that you can't do while testing. Once I learned how to test properly, TDD has been helpful, never a hindrance. In case you haven't read them `Test Driven Development By Example` by Kent Beck and `Growing Object-Oriented Software Guided by Tests` by Steve Freeman and Nat Pryce are great books
- gt_ 8y ago
  Great. I have not read them. I will though. Sounds like exactly what I need right now.

by gt_ 8y ago

eropple 8y ago

Testing basically breaks down into the following types (and you can flavor them however you want, but take this as a starting point): - test-last testing to test the implementation you just wrote - test-first testing to test the implementation you're gonna write - test-driven design, where the tests reflect the specification and are applied to the implementation So, with these on hand, here's my litmus test for TDD: Do I know what I'm building and why? You can't meaningfully do test-driven design if you don't know the what and the why. TDD tests need to encode "the business cares about this", and IME, the questions you are asking often arise when somebody doesn't really yet know what they're building. You're figuring it out. And that is okay, too! I'm not a TDD devotee (in that I would love to write code in a TDD fashion much more than I actually do, but I think it's probably the right answer for most situations where the unknowns have been solved or pushed out) and I think that you're describing a very common situation where writing tests while you're writing code, or maybe even after--though this is often fraught--is totally fine. I regularly build systems by writing tests to exercise bits and pieces of them in lieu of opening a REPL or running it through a command line; the Test Cops aren't gonna come get you if this works better during your exploratory phase. (It does mean your exploratory phase has some useful artifacts when it's done, though.) Put another way: if I have a spec, I can do TDD. If I don't, I can't, and I don't lose sleep over it.

gt_ 8y ago
Hilarious about the test cops. Testing seems to, so far, be a fairly wishy-washy task. The spec thing makes a lot of sense. The project I’m learning with is not ideal because the test environment takes a moment to boot but it’s peculiar and challenging me to consider real-world scenarios, which may or may not be a good thing but I’m near wrapping it up. It’s a plug-in for a few different content creation softwares. I would say I knew what I was building, but there have been unknowns about which particular approach will meet my standards and still be DRY. They all worked great with prototypes but I discovered some edge cases late in construction. I found TDD very satisfying but now I have an instinctual doubt about it. Your thoughts make a lot of sense. I guess one of the main things will do next time is avoid all the extra unit testing I did early on. I think I was honestly having too much fun. Someone should do research on if automated test coverage illicits the slot-machine effect.
swish_bob 8y ago
If you don't know what you're doing, how can you do it? I don't see how this is a TDD thing or not ...
- eropple 8y ago
  You've never written exploratory code before?

MiyamotoAkira 8y ago

The same that that structural test creates unnecessary coupling there will be other tests that create that coupling as well. It is a learning phase. You will realize that there are things that you can do and things that you can't do while testing. Once I learned how to test properly, TDD has been helpful, never a hindrance. In case you haven't read them `Test Driven Development By Example` by Kent Beck and `Growing Object-Oriented Software Guided by Tests` by Steve Freeman and Nat Pryce are great books

gt_ 8y ago
Great. I have not read them. I will though. Sounds like exactly what I need right now.