I’m just heading out of the gates with my latest AirPair project lunch_panoply. I’ll be sharing my progress along the way, by shedding a spotlight on some of the thinking and technology involved while test-driving the data-model and controllers over the next few posts.
If you’ve been reading my posts for a while, you may recall a post on speeding up your tests with Guard and Zeus, have a look at the link if you haven’t yet had an opportunity, and are interested in your Rails tests never taking more than one second to run!
Allow me to share with you all of the gems I’m starting out with while in the test-phase of this project.
One of the first things I learned about managing my Gemfile was that it’s definately OK to remove all the comments that come standard after a new rails project install. So my Gemfile may be arranged with a slight difference to yours, the difference of note being no more comments in the file.
I had to pay close attention to the order of the gems in the Gemfile’s
:development, :test groups defined on lines: 15-23. Once the gems are defined we can run
bundle install to install these dependencies into our application and can start by setting up Guard and Zeus to run properly.
Also we want to take a look at our
spec_helper.rb file to ensure that we have instructions properly defined there as well.
Note that in lines: 13-27 in the
spec_helper.rb file below, I’ve included some configs for FactoryGirl and DatabaseCleaner, the instructions for both of these gems can be found on their github repos and are pretty solid.
require statements on lines: 4-8 are in the order they should so that testing with all of these dependencies work properly. And while I haven’t always had an issue when placing these
require statements in a different order, it’s happened enough for me to now pay close attention to the order they’re listed.
I’ve also commented out line: 5, as
require 'rspec/autorun', if left uncommented will cause the command
zeus test to run duplicate tests (one set of specs failing and one passing) like so:
I’ve added the following lines to my
.rspec file in order to get the colors and formatting you see in the above illustration:
I have the
spec tree setup in a such a fashion as to satisfy the various conventions that the dependency gems prefer to run some TDD.
Firing it all up
Now that we have most of our tools configured, lets get headed in the direction of starting this all up.
First we want to type
bundle exec guard init in our terminal in order to create an empty Guardfile, and follow that up with
guard init zeus to add definitions to the blank Guardfile. Our next step is to type
bundle exec guard to get it running. Remember to always run Guard through bundler to avoid errors.
Your terminal should look something like the above image, if things are working properly. In this image, zeus started automatically. I’m not sure why this is off-hand, but typically typing
bundle exec guard will only return up until the line
To start the Zeus server we can
command + T a new terminal window,
cd into our project’s directory and type
zeus start. If the server starts properly, we’ll see something like so:
Looking at our final lines of zeus code in the above illustration we can see that green-output means the server is up and ready to do our bidding, seeing them in yellow-output means that the server is still attempting to bring itself online, and a red-output means that the server has attempted to start but crashed.
command + c will stop a server process. Remember to use this command before closing your terminal window housing the Zeus and Guard servers. Leaving the Zeus socket running while closing it’s window will make your next attempt at running it a bit of a hassle to rectify. I’ve had this happen so much to me while learning to become proficient in this approach, I think its worth mentioning how to correct this.
First I’ll receive an error that looks like so, if my last Zeus server usage was not terminated properly:
To fix this, we just follow the instructions to remove
.zeus.sock and then type
zeus start again. To find out if the
.zeus.sock is where it should be, our project’s root folder, we can type
ls -la (in caps for clarity that would be LS -LA). Here’s what that command will output:
And to remove the socket file we can type
rm .zeus.sock followed by
zeus start to start the server up again.
Off the Starting Block
And now we’re ready to verify that running our specs will go off without a hitch before we actually start test-driving our project.
I’ve already shared that we can run tests through Guard-Zeus by typing
zeus test spec. There are some additional command options I’ll include in this post in case you haven’t stumbled upon them yet.
zeus test spec/models will run only our model specs, the same command can be substituted like
zeus test spec/controllers or
zeus test spec/helpers depending on which sub-folder you wish to isolate when running your spec results.
zeus test spec/models/contact_spec.rb will run a particular spec file and we can also run one spec at a time by appending a line number to the end of our spec_file root like so:
zeus test/spec/models/employee_spec.rb:9 subsitutuing whichever line number in your spec_file you’d like to run.
And thats it! We’re now ready to start test-driving our data-model. Something I plan on covering in a near future post. As always, if you have comments or critiques, feel free to comment below.