The 30-30-30 Rule: Simplifying Test Automation with Cucumber, Ruby, and Selenium
The last six years have been a challenging yet rewarding journey for 3Qi Labs. We’ve executed millions of tests using open-source technologies across diverse projects and geographies. In the process, we’ve discovered a critical truth about writing automated test scripts:
How you build your automation (the design and architecture of scripts and frameworks) is even more important than what you’re building it to do (functional coverage, complexity, or depth of testing).
This realization has guided us, particularly in our recent work with Behavior-Driven Development (BDD) using Cucumber, Ruby, and Selenium WebDriver. To streamline our processes and enhance collaboration, we developed a simple yet powerful principle we call the 30-30-30 Rule:
- A Feature File should have fewer than 30 scenarios.
- A Scenario should have fewer than 30 steps.
- A Step should have fewer than 30 lines of code.
Understanding Cucumber and the 30-30-30 Rule
For context, let’s revisit the core components of Cucumber:
- Feature File: Describes what will be tested, broken down into scenarios for specific functionalities (e.g., creating or deleting a lead in Zoho CRM).
- Scenario: Represents an executable test for a functionality.
- Step: Defines the individual command for each line of the scenario (e.g., creating a new account).
The steps in a Feature File are powered by Step Definitions written in Ruby. Each Step Definition file contains the code that executes the logic behind the steps.
Why the 30-30-30 Rule Works
By adhering to the 30-30-30 Rule, we address three key aspects of automation:
1. Maintainability
Automation frameworks are often plagued by bloated and complex code, making maintenance a costly and time-consuming effort. Limiting the length of scenarios and steps reduces this burden, making scripts easier to debug, update, and enhance.
2. Readability
Clear, concise scripts are easier to understand, especially for team members unfamiliar with the Feature File structure. By minimizing the number of lines per step, you improve comprehension and make the test cases more dynamic, allowing concepts like structured scripting to shine.
3. Transfer of Ownership
Many of our projects involve building automation and handing it off to customer teams. Simplicity is key. Cluttered, complex code is harder to understand, maintain, or enhance—especially for someone who didn’t write it. The 30-30-30 Rule ensures smoother knowledge transfer.
Practical Application of the 30-30-30 Rule
Consider the following examples:
Feature File Example:
Feature: Zoho CRM Happy Path Tests
Scenario: Create a new lead
Given I navigate to the leads page
When I create a lead with "John Doe" and "john.doe@example.com"
Then I confirm the lead is created successfully Step Definition Example:
Then("I create a lead with {string} and {string}") do |name, email|
@browser.find_element(:id, 'new_lead').click
@browser.find_element(:id, 'name_field').send_keys(name)
@browser.find_element(:id, 'email_field').send_keys(email)
@browser.find_element(:id, 'submit_button').click
end
By keeping steps concise and scenarios focused, scripts remain clean and approachable.
Flexibility of the Rule
We acknowledge that the 30-30-30 Rule isn’t a hard-and-fast law. Complex applications or scenarios may require exceptions, but any deviation from the rule should have a clear, justifiable reason.
Why You Should Try It
If your automation scripts feel cluttered, hard to debug, or challenging to enhance, consider adopting the 30-30-30 Rule. Its simplicity encourages clarity, maintainability, and efficiency.
Do you have similar rules or methodologies that you enforce in your automation projects? Let us know—we’d love to learn from your experiences!
