The Stride Blog
Get the latest tips on agile software development so you can scale and embrace change.
When initially learning about test-driven development, it’s tempting to want to test everything using every kind of test. However, when building a valuable test suite, over-testing isn’t the best approach. This guide is primarily targeted at production applications with problematic test suites, as well as provide information that will be useful in all stages of development.
In part one of our series of Feature Driven Development, we provided an overview of what it is. In part two, we developed a simple app. Now, in part three, we will look at the differences between SimpleBDD and its primary competitor, Cucumber, and explore some tricks you can do to get the most out of SimpleBDD.
Having seen an introduction to feature-driven development using RSpec and SimpleBDD (part 1 of this series), let's use it to construct a to-do list web app, step-by-step. This isn't going to be a complicated app, but it will illustrate the process.
In an ideal world, everyone who makes Rails apps would do test-driven development. However, many do not because of the complexity of setup, the additional time it takes to write tests, and general laziness. I believe that by providing simple, powerful tools and techniques, and the guidance in using them, at least the first two factors can be eliminated. Then general laziness will become reason TO write tests rather than a reason NOT TO.
Your enterprise shouldn't just think like a startup. Act like one. Get our MVP launch guide to fix your MVP launch today.