Ruby Programming – ODIN Project – 5

odinTesting Ruby with RSpec

Step 1: Introduction to RSpec

Many tech companies these days rely on test-heavy methods of development.t familiar with it.

You’ve had some experience writing actual programs using Ruby. Presumably, you’ve been making sure they work by manually entering certain things in the command line over and over again.

Testing with RSpec lets you automate most of these activities. It also allows you to make sure your programs’ interfaces with the public are functioning properly. It allows you to have confidence in your code.

At the most basic level, RSpec is a “Domain Specific Language” (DSL) written in Ruby that is designed to help you test your Ruby code. You use it by including the rspecgem, which is really just a package containing 3 other gems – rspec-core, rspec-expectations and rspec-mocks. It’s configured so that, once you’ve got the gem included, if you’ve laid out your project folders in the right places, you can just execute the specs directly from the command line.

It’s difficult to find good resources to teach RSpec for free. There are some decent paid resources (listed in the “Additional Resources” section below) but the free ones are very dispersed. The way you’ll likely learn it is by knowing you want to do something and then Googling around for how to test it, or going through a tutorial where someone is using it.


Points to Ponder

Look through these now and then use them to test yourself after doing the tasks

  • How do you run an RSpec test suite?
  • How do you write a basic RSpec test?
  • What aspects of your methods should you test?
  • What is a stub?
  • What is a mock?
  • What is a double?
  • How are they different?
  • When would you use them?

Your Tasks

2. Watch this YouTube video Ruby for Newbies (https://www.youtube.com/watch?v=JhR9Ib1Ylb8&feature=relmfu) which writes some RSpec tests for a small bit of sample code in the Test-Driven Development (TDD) fashion.
https://www.youtube.com/watch?v=JhR9Ib1Ylb8&feature=relmfu
Uploaded on 10 August 2011
Ruby is a one of the most popular languages used on the web. We’re running a Session here on Nettuts+ that will introduce you to Ruby, as well as the great frameworks and tools that go along with Ruby development. In this episode, you’ll learn about the testing your Ruby code with Rspec, one of the best testing libraries in the business.
3. Read Treehouse’s Learn An Introduction To RSpec (http://blog.teamtreehouse.com/an-introduction-to-rspec) for a slightly more formal grounding in the basics.
4. Read through Better Specs { rspec guidelines with ruby } Introduction to ReSpec Guidelines (http://betterspecs.org/) which shows lots of examples of what you should and shouldn’t do with RSpec.

5. Look at Relish Project: RSpec Core 2.4 (https://www.relishapp.com/rspec/rspec-core/v/2-4/docs).  This is official documentation and is a good resource / reference.



Project: Testing Ruby

Time Traveling

A good way to get familiar with and begin contributing to a new project is to write tests for it. It’s also the best way to become familiar with a new code base. It’s pretty common for test code to ultimately take up twice as many lines of code as the actual project code!

Let’s go back in time and write tests for some of the code you’ve already written.


Your Tasks

1. Go back to the Building Blocks Project (http://bedford-computing.co.uk/learning/ruby-on-rails/ruby-programming-odin-project-1/) and write tests for your “Caesar’s Cipher” code. It shouldn’t take more than a half-dozen tests to cover all the possible cases. Do you remember how to make your tests run using $ rake?

2. Go back to the Advanced Building Blocks Project (http://bedford-computing.co.uk/learning/ruby-on-rails/ruby-programming-odin-project-1/) and write tests for any 6 of the enumerable methods you wrote there. In this case, identify several possible inputs for each of those functions and test to make sure that your implementation of them actually makes the tests pass. Be sure to try and cover some of the odd edge cases where you can.

3. Write tests for your Tic Tac Toe project (http://bedford-computing.co.uk/learning/ruby-on-rails/ruby-programming-odin-project-2/). In this situation, it’s not quite as simple as just coming up with inputs and making sure the method returns the correct thing. You’ll need to make the tests determine victory or loss conditions are correctly assessed.

4. Start by writing tests to make sure players win when they should, ie. when the board reads X X X across the top row, your #game-over method (or its equivalent) should trigger.

5. Test each of your critical methods to make sure they function properly and handle edge cases.

6. Try using mocks/doubles to isolate methods and make sure that they’re sending back the right outputs.


Project: TDD Connect Four

Hopefully everyone has played Connect Four at some point (if not, see the Wikipedia’s Connect Four article (https://en.wikipedia.org/wiki/Connect_Four)). It’s a basic game where each player takes turns dropping pieces into the cage. Players win if they manage to get 4 of their pieces consecutively in a row, column, or along a diagonal.

The game rules are fairly straightforward and you’ll be building it on the command line like you did with the other games. If you want to spice up your game pieces, look up the Wikipedia’s List of Unicode characters – Unicodemiscellaneous symbols (https://en.wikipedia.org/wiki/List_of_Unicode_characters#Miscellaneous_Symbols).

The major difference here is that you’ll be doing this TDD-style. Work out what needs to happen, write a (failing) test for it, then write the code to make that test pass, then see if there’s anything you can do to refactor your code and make it better.

Only write exactly enough code to make your test pass. Often, you’ll end up having to write two tests in order to make a method do anything useful.  It may feel a bit like overkill, but that’s the point of the exercise.


 Your Task

  1. Build Connect Four! Just be sure to keep it TDD.

 Additional Resources