The Behavior-Driven Development workflow will differ when we begin writing automated tests. And it will also require adherence to more specific rules.
In this lesson, we'll review the BDD process we learned in Intro to Programming. Then we'll address how this workflow changes with automated testing and the exact steps you should follow when developing programs using BDD.
Refer back to this lesson frequently. Keep it open as you code, and make sure you're following each step closely. Before long it will become second nature!
Here's how we've been using Behavior-Driven Development so far:
Here's what the BDD process will look like with coded tests. New steps are bolded:
This workflow is known as "Red, Green, Refactor":
You will be expected to follow this workflow for the rest of the course. Let's walk through what each step looks like:
We identify the smallest behavior the program must exhibit. This behavior should also remain true for the life of the program. For example, here are several projects we've created previously, and the simplest possible behavior for each:
falsefor a year that is NOT a leap year.
it('returns false for numbers not divisible by four') do expect(1999.isLeapYear).to(eq(false)) end
it('returns false for numbers not divisible by four') do describes what this particular spec is testing for. In our case, it's ensuring our
isLeapYear() method correctly returns
false if a year provided to it is not divisible by 4 (since leap years are divisible by four).
expect(1999.isLeapYear).to(eq(false)) outlines what we expect to occur (that is, the circumstance under which the test passes). Here, if we call
isLeapYear() on the year
1999, and it successfully returns
false the test passes. If not, it fails. This is similar to manually testing applications by providing input and confirming we receive the correct output.
This is the red part of "Red, Green, Refactor", because failing tests display red text.
Before coding we need to confirm our test fails. Sometimes tests will incorrectly pass, usually due to being written incorrectly. If a test passes before we code the behavior it is responsible for testing, something is likely wrong. This is an indication that we should take a closer look at the test itself before adding logic.
Next, we add just enough logic to pass our spec. We focus on only adding the bare minimum to both keep our code DRY, and to ensure we're only focusing on one behavior at a time.
This is the green part of "Red, Green, Refactor, because passing tests display satisfying green text.
Run the test(s) again. Make sure they pass. If not, read the failure messages carefully. They should describe why the test failed. Repeat steps 4 and make changes accordingly. Run test(s) again after making any changes. Do not move on to subsequent behaviors until the current tests passes.
This is also the green part of "Red, Green, Refactor.
As soon as we've repeated this process enough to have multiple tests, confirm that adding the new behavior hasn't broken previous behaviors.
If any tests fail, carefully read the error messages and revisit the logic. If you followed BDD closely, you'll know with certainty that the most-recently implemented code caused this error. Address the bug, run tests again, and continue to read any error messages. Repeat this process until all tests pass.
As you may have guessed, this is the refactor part of "Red, Green, Refactor".
Once logic is working, and all specs pass, go back and refactor your code if possible.
If you are able to refactor, repeat step 6 to confirm tests still pass.
Repeat this entire process for every incremental behavior until the application is complete. After addressing the simplest possible behavior, move to the next simplest, then the next, until all behaviors the program requires are present.
It is required to follow this workflow and write automated tests for every application you create moving forward. Bookmark this lesson and refer back to it as you code, or save the summary from the cheatsheet somewhere you can easily reference. You're not expected memorize each step immediately. But follow this workflow closely as you code upcoming projects. Pretty soon, it'll become second nature!
The "Red, Green, Refactor" BDD Workflow looks like this. Reference this lesson or cheatsheet until this workflow becomes second nature: