I built my first Rails app ten years ago. I’ve tried all methods, and if there’s one thing I’m sure about, it’s that I can’t get it to work without writing tests. And writing the tests first has helped me hone my programming skills the most.

It’s very easy. We want to feel and be as productive on Day 1000 as we are on day one of the project. We want to be fast. For that we need clean code.

We can’t fix everything in the first pass, so we need to refactor. However, we can’t refactor under the constant fear that we’ll break stuff and send the bug into production without knowing it. We need confidence that when we break code, we can quickly detect and fix the problem.

Where does confidence come from? Automated test suites give us confidence. Trust us we can change, remove or add new code, and as long as our tests pass it won’t be a big problem.

So if there are tests bases, let’s write them first. Do this for a while, and you’ll see how clean and efficient both your code and tests are.

Understanding the “behavior” approach
When implementing test-driven development (TDD), developers can easily fall into the trap of using unit tests to test what an object or method is, which is much more useful.

An example would be writing a test that asserts that a collection of observations is exclusively an array, and not one of its unique features, such as being sorted by time. In most cases, it doesn’t matter if we change the implementation of that collection to return a custom enumerable class.

Behavior-Driven Development (BDD) focuses on behavior at all levels of development—what one thing does.

Initially, the word “behavior” may sound strange. Another way to frame it is to think about the details. We can describe each low-level method, object, button, or screen to someone else – and what we’ll describe is actually a behavior. Adopting this approach changes the way we write our code.

“Given / When / Then” Communication Patterns

Most of the problems in software development are communication problems. For example, Product Manager fails to describe each use case of the proposed functionality. Developers misunderstand the scope of a feature. The product team doesn’t have a protocol in place to verify whether a feature is done or not.

Given, When, Then are simple words we can use to describe a complex attribute, code object, or a single method in a similar way. This is a pattern that all team members in different roles can understand.

These expressions are also built-in to many testing frameworks, such as Cucumber. Clear formulation and solution of the problem we need to implement helps us to write better code.

Overview of BDD Tools for Rails
Ruby on Rails was the first web framework to ship with an integrated testing framework. This served as a springboard for the further progress of the craft.

At the same time, increased productivity in developing Web applications with Ruby’s Expression and Rails quickly attracted many experienced and high-profile engineers to the community.

When you generate a new Rails application with the default options, it sets up the scene for testing using test/unit, a testing library that comes with Ruby. However, there are tools that make it easier to implement BDD. I recommend using RSpec as the main test library and Cucumber as the main test library for writing high level acceptance tests.

We can use rspec to specify the whole system, however we can also use a tool that helps us write and communicate naturally.

As I mentioned in the first chapter of this guide, we want to test each new feature in the analysis phase. To do this, we need customer acceptance tests to drive development of the code that will actually implement the feature.

If you’re a developer working in a sufficiently complex organization, you may want someone else, such as a customer or a product, manager to write the acceptance tests for you (disclaimer: I’ve never worked in such an environment). In most cases, the developer writes them. This is a good exercise, as it helps us better understand what we need to build. Cucumber provides the language and format to do this.

Cucumber reads plain text descriptions of application features arranged in scenarios. Each step in the scenario is implemented using concrete code, and it automates the interaction with your application from the user’s point of view.

Leave a Reply

Your email address will not be published. Required fields are marked *