“We want to ship rock-solid features and do it quickly, but our lack of good tests and testing practices is slowing us down”
Development teams (even “teams” of one developer) who don’t have great testing practices in place often experience troubles like the following.
Developers skip tests because their testing skills aren’t strong enough
Most developers who don’t write tests are held back by a lack of skills, not a lack of willingness. Developers struggle with blockers like “I don’t know what to write tests for,” “I know I should be testing, I just don’t know how to get started,” “It takes me forever to figure out how to write each test,” and other obstacles. One statement I came across was “No matter how much I read about testing, I just don’t get it.” Testing is hard to learn.
And so developers skip tests because what other option do they have? And a lack of testing skills is compounded when…
Tests get skipped because the existing code was written in an untestable way
Some code is more easily tested than other code. Code that’s modular and loosely coupled is easy to test. Small classes and small methods are easy to test.
What’s nice is that if tests were written from the beginning, the code underneath has to be modular and loosely coupled and all that because it would be physically impossible for it not to be.
Unfortunately, most projects that were written without testing in mind are full of code that is, in its current state, untestable. So not only might the development team lack testing skills but they’re facing the extra challenge of trying to test untestable code. They’re not likely to get very far very quickly.
Even if developers do know how to write tests, and even if the code is testable, you still might be dealing with the very common problem of…
Tests get skipped because there isn’t a process to enforce that tests get written
I once worked at a startup where our test coverage was decent enough but needed improvement. So, as a team, we agreed on a rule: all new code gets tests.
Rule did not result in an immediate transformation of all the developers’ deeply-ingrained habits, if you can imagine that. You can’t change longstanding habits and culture by simply issuing a rule. So what happened was that untested code still slipped through and got deployed.
It’s not just habits, either. Even if the developers have written tests on previous projects, it may be the case that…
Tests get skipped because the codebase lacks testing infrastructure
You can’t go from having zero tests for months and then one Tuesday decide you’re going to start adding tests every day from now on. You have to have the infrastructure for adding the tests. And even before that, the development team and development leadership have to get together and get on the same page regarding testing tools testing approach, etc.
And even if you have testing infrastructure in place but not many meaningful tests, you might have a problem because…
Tests get skipped because there are no good examples to follow and no repeatable test-writing process to follow
When developers don’t have a step-by-step formula to follow for writing tests, and when developers can’t look to the existing test suite as a place to find examples of well-written tests, it can add friction to the job of adding new tests.
All these obstacles to writing tests are problems in and of themselves. There are also a number of symptoms experienced as a result of lacking tests.
Features take forever to build
It takes time to write tests, but on the other hand it takes even more time not to write tests. How many times have you seen a developer hand a “completed” feature off to a QA person or manager only to have the feature break in the first five minutes of use? Manual testing is tedious and time-consuming and developers are notoriously bad at finding their own bugs. Programmers like to automate things. They typically don’t enjoy carrying out manual tests. This is why…
Bugs pop up, then get fixed, then pop up again
Few things are more frustrating than seeing a bug get fixed only to see that same bug pop up again. If you have no automated tests, there’s not necessarily anything stopping this from happening. And so, in fact, it often does happen.
If there are tests, they’re messy and hard to understand and maintain
It’s one thing to be skilled enough to get a test to simply work. It’s another level of skill to be able to grow a test suite over time in such a way that it doesn’t collapse under the weight of its own complexity.
Deployment is scary, slow and expensive
If you don’t have a robust test suite covering your application’s features, you have two deployment options.
One option is to pay QA people to go through a battalion of manual tests, which may take a few hours or maybe even up to a couple days. This method is effective but it translates to infrequent deployments. How many times per month are you going to want to go through the rigamarole of having the QA team manually go through the whole application top-to-bottom? Most teams I’ve seen who operate this way only deploy once a week, once every two weeks, or worse. Meanwhile companies like Amazon purportedly deploy code every 11.7 seconds.
The other option is to just YOLO it and deploy without testing. Some companies really do do this, despite the fact that it’s obviously quite risky. You save yourself the expense of taking the time to run through a thorough manual test suite, but then you pay for it when nasty production bugs are introduced. If these deployment disasters happen enough times, stakeholders get nervous about deployments, and so deployments happen even less frequently—paradoxially making each deployment even riskier.
What if instead, your development team had strong testing skills with a solid test suite covering the codebase?
Every new feature really does get a test
Every developer would write the test code just as easily as writing the code for the feature itself. Not only that, but the development process would be more enjoyable because writing tests actually makes it easier to think through what needs to be done. And as an added bonus, the code would end up cleaner—meaning less expensive to maintain.
Features could get delivered just once
Imagine walking through a developer’s “finished” feature and it really is finished. Because a test case was written for each item in the feature’s specs, you can run down the list of requirements and each one is present and working correctly.
Feature cycle time is shorter
Because there’s less back-and-forth between QA and development, each feature can be built faster and less expensively.
Deployments are frequent and easy and practically a non-event
Once you get to a good level of test coverage, deployments can happen almost as much as you want. Every time a feature branch is merged in, the test suite automatically gets run and, assuming the test suite passes, the feature gets deployed. (And if the test suite doesn’t pass, the new code is of course safely held back from getting deployed to production.)
This means delivering value to customers faster. It also means happier internal stakeholders.
Development is faster and more predictable in general
Without the wildcard of frequent regressions and production fires, developers are free to focus on building features. Because of the lowered level of risk and uncertainty, timelines are more easily predictable, and it becomes easier to actually stick to timeline commitments (or at least come closer than before). The faster and more predictable the development team is, the more the development team is able to be respected and trusted by other parts of the organization.
Introducing: Rails Testing Makeover
Rails Testing Makeover is a four-week program that will help you achieve two particular results.
First, you’ll have an improved test suite. If you had few tests, you’ll have more. If your tests were messy and hard to understand, they’ll be clearer.
Second and more importantly, your team will have stronger testing skills. They’ll no longer be confused about what to write tests for or how. They’ll know how to ensure that writing tests actually get written for each feature. They’ll know how to write clean, understandable test cases.
How it Works
Rails Testing Makeover is a hands-on service in which you’ll get personal attention from me, Jason Swett.
Because my services are in high demand and I have limited availability, I’ll only be offering Rails Testing Makeover a few times per year. Because of my limited availability, I want to make extra sure that the few clients I work with are the ones whom I can help make the highest impact and achieve the best ROI.
The first step of the process is an application to make sure we’re a good fit. You’ll tell me what exactly your challenges are, what you expect to get out of working together, etc. You can also specify on the application whether you’re 100% ready to move forward or if you’d like to have a call to mutually explore whether we’re a good fit to work together.
If we decide together that we’re a good fit, payment is rendered and we can begin working together.
Rails Testing Makeover is, again, a four-week program. On the Monday of the first week I’ll have a call with you and/or your development team to discuss in greater detail where your challenges and opportunities lie. I’ll also take a look at your test suite and make note of what I judge to be opportunities for improvement.
By the end of the first Tuesday, I’ll deliver a set of recommendations to the team and assign some “homework” to be done between then and the next Monday, which may include recommended reading material.
Each Monday thereafter, I’ll have a call with you and/or your development team where we a) briefly discuss how things went in the time since our last meeting, b) do some live coding together on your actual test suite, and lastly c) talk about what to do next. At the end of the call I’ll send a summary and more “homework” in an email.
I’m Jason Swett, host of the Ruby Testing Podcast and author of Rails Testing for Beginners.
I’ve taught programming all over the world for clients like HP and Deloitte and I’ve delivered talks at conferences like RailsConf and RubyConf India.
My background includes coding for clients as well as helping development teams improve their productivity, their predictability, and of course, their testing skills.
We need testing help, but not exactly with the things you list. Would it still make sense to work together?
A big benefit of Rails Testing Makeover is that it’s customizable to your particular needs, at least of course to a reasonable extent. If you’re not sure, just reach out to me at email@example.com and ask.
Will you sign my NDA?
I have no problem signing your NDA and/or whatever other jumping through whatever other administrative hoops are in place. Those steps will take place after payment is rendered.
What if I’m just one developer? Can I still get help?
As long as everything else is right, there’s no reason I won’t work with a “team” of just one developer.
Pricing for Rails Testing Makeover and How to Apply
The 4-week Rails Testing Makeover program is $850 per developer, due in advance of the service.
I offer a 100% money-back guarantee. If after completing the program you are unsatisfied for any reason, just let me know and I’ll issue a full refund.
Application is currently closed. I plan to open up applications around early/mid August 2019 at which time I’ll be accepting one client for the service. If you have any questions about Rails Testing Makeover in the meantime, please contact me at firstname.lastname@example.org