Writing basic tests with Rspec
Why should you write tests with rspec when writing a project? Why not just write a bunch of instances manually manipulate that data? This can get a little messy. It gets tiresome having to test many specific pieces of data in different ways. Writing your own tests is grounding in a few ways. It allows you to think about your project and how you want your code to work by writing tests for it before you even start. For this reason, writing tests for your labs is considered “step 0” in TDD.
It not only helps you think about what you want the specifics of your projects it helps you keep track of how your code is working as you build your project. If you get a test to pass at one point while working on your project, but as you start to build your project, if that test then fails then you know you’ve changed something that was working before. Another benfit of writing rspec tests is that it allows others who are viewing your code a general idea of what the code is doing.
Let’s start testing
To write test first we need to set up out enviornment. We need to make sure that our project folder has the rspec gem.

We store our spec files in a spec folder. Let’s say we’re trying to build a database of libraries and their books. At this point we know that we want an object to be a book. So we want to create a class of “Library”. We would write a library class file in our lib folder and a corresponding spec file in our spec folder.
Now that we have a basic environment set up we want to think about what we want our Library class to do. So let’s write a test for it. We want to make sure that we require our spec folder to be running both rspec and the file we’re trying to test, so at the top we write a require line for each.

If we try and run it now we get…

Because we don’t have anything written just yet, there’s nothing for Rspec to test, so it throws an error. If we make a class of Library the opositie happens. We get the green light but we have 0 out of 0 tests passing.
Although there’s nothing actually written in our code, we still have a general idea of what we want. When we initiate an instance of Library, we would expect to have a name, and probably some books.
At this step, since we’ve thought about what our library might need as an object, we realize that there’s another object associated to it — books. So we need to write some tests for a book object and the properties it needs and how it interacts with our library object.
So let’s write some test for our Library and book objects. We know that our Library will need a name and be able to show the books it has, and we know that a book needs a name. These are some tests for this:

- When we write a test we want to start with
describe. It starts a block of Code and it also come up in our description in our tests. It doesn’t have to be an object, like Library as I’ve put in the start. I can be anything. This is just a line that shows up as text. letsets a variable for us. It takes in a symbol as a variable and whatever follows it becomes what’s housed in that variable.itis similar to describe, only this is the text that turns red or green. The code that is after the do is what our test is testing for.
Let’s make the basic classes and see what happens when we test.


This is what’s produced when we test. The higher level describe block is the text in the shortened test and the it blocks become the specific tests. Whatever was written for after do on the it becomes what rspec is testing for .
At this point we know what to do! This is how we all test in learning environments. We have to see what the specs are asking of us. Testing is so much more than just a learning tool. Its a great way to let people get a look into the specifics of your code without having to read the code itself, it allows you to keep track of your progress and more importantly it allows you to see if future bugs arise.
