Article

Cucumber Rocks – But it’s not a replacement for unit tests

Jason Sendelbach

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

I admit that cucumber is awesome. It apparently was the big thing at Rails Conf this year. I love that my BA can write the requirements, I can throw them into a feature file, and get feedback on my progress of the feature is done.

Cucumber is also an excellent choice for getting coverage on a legacy code base. Many of our clients have existing applications that were developed by cheap firms. They finally realize that they should have gone with a development company that writes automated tests, and works in a true agile manner. When initially looking at the code, we often get chills. There are usually zero tests. Most of the code sits in huge controller methods. We generally will use cucumber to start to get coverage for the features that the client wants changes to. We do write unit and functional tests, but we generally only assert the things we are changing. Over time, the unit and functional test coverage increases, and when we make changes we generally will refactor lots of the existing code base.

With that said, I have seen the use of cucumber on some of our projects change the way some developers code. They go from true TDD to crappy non-TDD. Many methods on the model don’t have unit tests! How can we call this TDD?

I do admit that the functional tests can be a lot lighter, as you are getting coverage from the cucumber suite of tests. However, It doesn’t mean that you can skip writing unit and functional tests.

This is how I incorporate cucumber into my development, while still maintaining 100% code coverage.
1. Write cucumber tests from the acceptance tests from the requirement
2. See all of the tests fail
3. Write unit tests, see them fail, write the code until the unit tests pass.
4. Write functional tests, see them fail, write code until the functional tests pass
5. Continue until I think the feature is fully implemented
6. Run the cucumber tests and see if anything still fails. – Add unit/functional tests to address failing cucumber tests. Once all tests pass, run the test coverage to ensure there are no holes (this generally doesn’t happen, as I am practicing TDD).

Related Services: Custom Software Development

Related Posts

Article

Climbing the Mountain of Regulatory Documentation for SaMD

Article

5 Keys to Integrating UX Design With Agile for SaMD

Article

Building & Scaling a Successful Cybersecurity Culture