What Is The Red Green Refactor Cycle
Tags: refactoring, tdd, testing, cleancode
Published: 2020-09-01 11:44:03

---
title: What Is The Red Green Refactor Cycle
published: true
date: 2019-03-29 00:00:00 UTC
tags: 
canonical_url: https://ellehallal.dev/blog/2019/03/2019-03-29-the-red-green-refactor-cycle/
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/sl8tzkr0xwqpv4o0miwu.png
tags: #refactoring, #tdd, #testing, #cleancode
---
<center><h3>Originally posted at <a href="https://ellehallal.dev" target="_blank">ellehallal.dev</a>👩🏽‍💻</h3></center>

---

This week, I have continued creating a human vs. human [Tic Tac Toe game in Ruby](https://github.com/ellehallal/ruby-tic-tac-toe), using Test Driven Development. I have also been trying to get familiar with a number of principles and rules, such as SOLID principles and the Four Rules of Simple Design.

When creating Tic Tac Toe, Test Driven Development is helping me to break down the game into small chunks. I still have a way to go, but the red, green refactor cycle is helping me to write cleaner code.

* * *

## Red, Green, Refactor cycle

### Red

The _red_ stage means that a test should be written and it should fail. This means not writing any code related to the test yet. In addition, it’s important to run the test to ensure it fails. Here’s an example of a test in my Tic Tac Toe game:

```java
it 'returns false if there are available spaces on the board' do
  board = Board.new([1, 2, 3, 'x', 5, 6, 7, 8, 9])
  expect(board.complete?).to be false
end
```

### Green

The _green_ stage means code should be written to pass the test. At this stage, the code doesn’t need to be the cleanest, just enough to make the test pass.

The simplest way of passing the above test would be to create a method namedcomplete?, which simply returns false. Here’s my initial attempt, which passed the test:

```java
def complete?
  available_squares = @squares.count { |square| square.is_a? Integer }
  available_squares == 0
end
```

### Refactor

The _refactor_ stage refers to writing a cleaner version of the code and still pass the test. In Sandi Metz’s presentation on [SOLID Object-Oriented Design](https://www.youtube.com/watch?v=v-2yFMzxqwU), there are a number of factors to consider when refactoring:

- Is it DRY?

- Does it have a single responsibility?

- Does everything in it change at the same rate?

- Does it depend on things that change less often that it does?

Looking at the method above, it appears to be DRY. However, it does have more than one responsibility.

- Counting the amount of available squares

- Returning true or false depending on the amount of available squares

My understanding is there should be two separate methods. With this in mind, another test was created to test a method counting the amount of available squares. The related code in complete? was extracted and added to the new method:

```java
//test
it 'returns the amount of available squares' do
  board = Board.new(['x', 2, 'o', 4, 5, 6, 7, 8, 9])
  expect(board.available_squares).to eq(7)
end

//method
def available_squares
  @squares.count { |square| square.is_a? Integer }
end
```

The refactored `complete?` method is now doing one thing: returning true or false depending on the amount of available squares:

```java
def complete?
  available_squares.zero?
end
```

I still have a way to go to adhere to the Single Responsibility Principle throughout the Tic Tac Toe game. Following the red, green, refactor cycle and the points on refactoring are helping to apply this principle.

* * *

## Helpful resources:

- [Sandi Metz — SOLID Object-Oriented Design](https://youtu.be/v-2yFMzxqwU)
- [Beck Design Rules](https://martinfowler.com/bliki/BeckDesignRules.html)
- [The Cycles Of TDD](https://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html)