• Input:[2, 4, 1]
• Output:[1, 2, 4]

When you run this test, you may see an error message like:

As you can see, the purpose of this phase was to define what you want to implement. The resulting error message from this test informs your approach to implementation. At this point, you are considered “in the red.”

The green phase is where you implement code to make your test pass. The goal is to find a solution, without worrying about optimizing your implementation.

In oursortArrayexample, the goal is to accept an array like[2, 4, 1]and return[1, 2, 4].

I decide to approach the problem by writing a loop that iterates over the array, and moves the current number over if it is larger than the number to the right. I nest this loop inside of a loop that repeats until all of the numbers are sorted (the length of the array). Sorting an array with[3, 4, 5, 6, 2, 1]would look like:

After I implement this, I should see a passing message that looks like:

At the end of this phase, you are consider “in the green.” You can begin thinking about optimizing your codebase, while having a descriptive test if you do something wrong.

In the refactor phase, you are still “in the green.” You can begin thinking about how to implement your code better or more efficiently. If you are thinking about refactoring your test suite, you should always consider thecharacteristics of a good test, MC-FIRE. If you want to think about refactoring your implementation code, you can think about how to accomplish the same output with more descriptive or faster code.

Let’s take a moment to think about how I would approach refactoring mysortArrayfunction. After doing someresearch of sorting methods, I find that I implemented thebubble sort method, which, it turns out, is not a particularly fast sorting method.

I choose to change the method I use insortArray()to themerge sort algorithm, because it has a faster average sorting speed than bubble sort.

As I refactorsortArray(), I have the safety net of my test to notify me if my implementation goes off the tracks, and returns the wrong answer. When I complete my refactor and run my suite again, I receive the following output:

Do you notice anything different about this output versus the output we received at the end of the green phase?

The new test code ran faster than before. The(7ms)next to1 passingis shorthand for seven milliseconds, the amount of time it takes to run the test. At the end of the green phase, our test suite took nineteen milliseconds. Although a twelve millisecond difference is trivial here, the amount of time it takes to run a test suite increases considerably as your codebase grows.

You may not always need to refactor your codebase. However when you’re in the green, it’s important to ask a few questions before putting yourself back “in the red”. Below is a list of questions you should ask yourself when you’re considering a refactor:

• Can I make my test suite more expressive?
• Does my test suite provide reliable feedback?
• Are my tests isolated?
• Can I reduce duplication in my test suite or implementation code?
• Can I make my implementation code more descriptive?
• Can I implement something more efficiently?

If you take time during the refactor stage to ask these questions, you will likely end up with a more complete, reliable, and fast piece of software.

In this article, you saw an example of how you can use TDD to improve confidence that your code is working as expected. You also saw how to use an existing test to keep you on track while you refactor implementation code.

If you use red, green, refactor TDD to approach large software implementation problems, you will find yourself saving time, while implementing a more robust solution than you otherwise would have.

'The Codecademy Team, composed of experienced educators and tech experts, is dedicated to making tech skills accessible to all. We empower learners worldwide with expert-reviewed content that develops and enhances the technical skills needed to advance and succeed in their careers.'