Cucumber/Turnip Testing

There once was a time when I was a young developer when I wrote code and tested it in the UI or other ways, but never wrote tests in any kind of expressive business language.

I then began to work for clients that requested it. As we all are when doing something new or something that slows us down, I resisted with all of my might, but did what the client wanted. Wonder of all wonders, when I wrote tests and concentrated on writing tests that mirrored business functionality, it actually caught bugs in my code.

Now, will all bugs be found by writing tests? No, unfortunately not. Will a large majority be caught? A resounding YES!

Recently I've been writing most of the tests for my clients in Turnip, a way of running tests written in the Cucumber syntax inline with my RSpec tests. I haven't looked for anything newer in a while, so I may be a little bit behind the times, but it's really nice having them run inline with my other RSpec tests rather than having to write special rake tasks to run the Cucumber tests at a different time. At a previous client I would always forget to run one or the other set of tests.

As a business owner you may wonder why developers or anyone else would spend the time or money to write these tests. That's a very good question. The best answer to this question is: You'll spend the time and money sometime. If not now, a year from now when you want to add that cool new feature.

Case in point: I have a wonderful client who has a Rails app that is about 8 years old (in 2017). They have an approximate code coverage of 38%, and unfortunately, most of that code coverage is outside of some of the most critical parts of their code. I recently completed a project for them which had to change and update some of those core components. It has been a challenge to figure out if the changes that I'm making have unintended consequences. The project has taken a good bit longer than it should have just because I am either having to manually test way more than I should, or I'm going back and actually writing the tests that should have been there before.

I definitely understand the time to market / cost issues that come with writing tests for the code that will run your business. Unlike some of my BDD/TDD brethren, I will sometimes be OK with limiting some test coverage in the short term for a time to market advantage, depending on the team that I'm working with and my client's willingness to circle back and write the tests that we should have done during the initial phase.

In general, however, for the best return on your investment, the highest quality code for you and your customers, and the best sleep for you, I recommend writing good tests and maintaining them for the long term. They will pay dividends for years to come.