3 ms·

I have been doing professional RoR development for a couple of years. I have made several attempts to use proper TDD, but always revert back to old habits. I c

I have been doing professional RoR development for a couple of years. I have made several attempts to use proper TDD, but always revert back to old habits. I can think of four reasons why this happens to me: a) there aren't many good examples of applications built using TDD available. see http://s831.us/PM6jkb http://s831.us/PM6jkb , b) TDD becomes very difficult when your application incorporates complex 3rd party data sources and APIs, c) feels like you are writing the application twice (once in Cucumber/RSpec and once in RoR), d) pressure to "get something done" results in backsliding. By contrast, I have been running for exercise the last couple of years. Running is not competing with an established habit and I see immediate benefit from almost each run. I highly recommend getting a FitBit or Nike+ SportWatch GPS and signing up for a stretch goal. For example, successfully ran the Dipsea this spring. Now training for half marathon in October.

dpcx 14y ago
My problem with TDD is that I never know what I need to test, until I've at least started spec'ing the project, and I don't do that on paper. I do that in code.
- Scottopherson 14y ago
  I face this issue as well. I see the value in TDD but at the beginning of a project I often end up wasting a lot of time churning through articles on TDD and researching the documentation of various test frameworks because figuring out what I need to test before I start writing code never seems to click with me. I believe it's a skill that I simply need to improve but my progress is slow-going which often gets frustrating.
- vlisivka 14y ago
  Tests highlights problems. At beginning of the project they are showing that there is no good spec's for the project. This is the problem which you need to fix first.
latortuga 14y ago
I've only recently become much better about testing and TDD in general and it's only since I actually started trying to do it. It's much more rewarding than I ever gave it credit for and it gives me an opportunity to keep my code from violating a lot of bad design practices. Addressing a few of your points: b) Absolutely, it's not easy to keep testing when incorporating 3rd party data sources and APIs. I've found that Dependency Injection is a hugely useful tool for attacking this kind of situation. Take this small snippet: def save_image(s3_library=AWS::S3::S3Object) s3_library.store(...) end I just was working on this today. Typically you would put your AWS call in the method - this separates it into an injectable dependency that you can mock and set expectations on in your tests. In fact, once you start doing this, you quickly realize why the Law of Demeter is such a good idea! Stick to testing only the behavior of the current class and relentlessly stub and set expectations for collaborators - each collaborator already has its own set of unit tests (presumably) so testing the results of collaborators does not add value and makes tests harder to maintain. c) It sure does feel like you're writing the app twice and I've fought with myself over this very issue. I have compromised with not forcing everything to have a test and instead to test things that aren't default crud. Alternatively, look at it as an investment in maintainability and refactorability. I recently switched away from using Cucumber to using Rspec's built-in integration testing methods and I feel a lot happier writing integration tests. I encourage you to evaluate why you think Cucumber is a good idea and seriously consider discarding the layer of indirection that gherkin introduces.

dpcx 14y ago

My problem with TDD is that I never know what I need to test, until I've at least started spec'ing the project, and I don't do that on paper. I do that in code.

Scottopherson 14y ago
I face this issue as well. I see the value in TDD but at the beginning of a project I often end up wasting a lot of time churning through articles on TDD and researching the documentation of various test frameworks because figuring out what I need to test before I start writing code never seems to click with me. I believe it's a skill that I simply need to improve but my progress is slow-going which often gets frustrating.
vlisivka 14y ago
Tests highlights problems. At beginning of the project they are showing that there is no good spec's for the project. This is the problem which you need to fix first.

latortuga 14y ago

I've only recently become much better about testing and TDD in general and it's only since I actually started trying to do it. It's much more rewarding than I ever gave it credit for and it gives me an opportunity to keep my code from violating a lot of bad design practices. Addressing a few of your points: b) Absolutely, it's not easy to keep testing when incorporating 3rd party data sources and APIs. I've found that Dependency Injection is a hugely useful tool for attacking this kind of situation. Take this small snippet: def save_image(s3_library=AWS::S3::S3Object) s3_library.store(...) end I just was working on this today. Typically you would put your AWS call in the method - this separates it into an injectable dependency that you can mock and set expectations on in your tests. In fact, once you start doing this, you quickly realize why the Law of Demeter is such a good idea! Stick to testing only the behavior of the current class and relentlessly stub and set expectations for collaborators - each collaborator already has its own set of unit tests (presumably) so testing the results of collaborators does not add value and makes tests harder to maintain. c) It sure does feel like you're writing the app twice and I've fought with myself over this very issue. I have compromised with not forcing everything to have a test and instead to test things that aren't default crud. Alternatively, look at it as an investment in maintainability and refactorability. I recently switched away from using Cucumber to using Rspec's built-in integration testing methods and I feel a lot happier writing integration tests. I encourage you to evaluate why you think Cucumber is a good idea and seriously consider discarding the layer of indirection that gherkin introduces.