This is really a warmup – you’ll get a chance to poke around HTTP requests from the command line (IRB actually) and also to play around with a new gem called
rest-client. This is a useful (and powerful) gem which helps you make HTTP requests. You can use it to do the basic stuff we’re doing here or much more complicated authentication requests.
You may find yourself using Rest Client down the road if you need to communicate with another web service that doesn’t have an API library already written out for you (which is pretty rare these days). Or if you get the inclination to test your own API from the command line later.
$ gem install rest-client
…that’s it. The point is to get familiar with making HTTP requests using your command line, which should prepare you for making them from within a Rails app later.
Send us your solution so we can show others! Submit a link to the Github repo with your files in it here using any of the methods listed on the contributing page. Please include your partner’s github handle somewhere in the description if they would like attribution.
In this project, you’ll dive right into the tutorial by building the site’s static pages. In the fourth chapter, you’ll get a refresher of the Ruby concepts which will be useful to you along the way. Even if you’re good with Ruby (for instance completing the Ruby course), this is a good chapter to look over to see how some of those concepts are applied to Rails.
One aspect of the Ruby on Rails tutorial which we haven’t covered deeply is testing. You got a good taste of it in the Ruby course but there are some more moving parts when it becomes applied to Rails.
Michael Hartl does a pretty good job of explaining what’s going on during the Rails Tutorial and the syntax of MiniTest is relatively straightforward, and easily parallel to RSpec. If you’ve been following the curriculum up until now, you should find testing in Rails to be a natural transition from plain Ruby tests (and actually a bit more interesting because you get to play with webpages).
If you don’t feel comfortable with testing Ruby yet, it can feel like you’re learning two languages at once. Don’t be discouraged if you end up scratching your head a bit… it takes some getting used to. Luckily RSpec only uses about a dozen different methods again and again and again, the trick is just knowing which order to put them in.
The tutorial covers more specifically the practice of “Test Driven Development”, where you actually write the tests FIRST and THEN write the code to make them pass. That’s helpful for many reasons, not least of which is that you get to make sure your test actually fails if the code doesn’t work. It also keeps you honest by making you only write just enough code to make your tests pass (so your code base stays lean and clean). It can take some getting used to but it is a software development practice that is becoming more and more common these days.
90% of you will need to learn Rails testing and this is the best way to do it. That 90% covers everyone who will be seeking a job as a web developer or who is looking to put together any websites more complicated than simple registration pages. For the other 10%, you should be okay skipping past the testing but I encourage everyone to give it a shot. Otherwise you’ve got no way of knowing if your application is working properly or not.
This is an example (listing 3.15) from the tutorial:
# test/controllers/static_pages_controller_test.rb require 'test_helper' class StaticPagesControllerTest < ActionController::TestCase test "should get home" do get :home assert_response :success assert_select "title", "Home | Ruby on Rails Tutorial Sample App" end test "should get help" do get :help assert_response :success assert_select "title", "Help | Ruby on Rails Tutorial Sample App" end test "should get about" do get :about assert_response :success assert_select "title", "About | Ruby on Rails Tutorial Sample App" end end
This syntax will be a bit different from the testing you have done before, that’s because it uses the MiniTest testing framework instead of RSpec, which you have been so far. The syntax is a little different but the concepts are all the same so you shouldn’t have much trouble understanding minitest tests. This is an “integration” or “feature” test, which means it deals with making sure your higher level user flows (as the user moves from one page to the next) behave as expected. You’ll also get to do “unit tests”, which are meant to specifically test narrow pieces of functionality like model methods. Both are important.
I’ll do a brief walkthrough of what’s going on in this example just to get your mind warmed up for testing. Refer back to the previous lessons on testing and additional resources below for better explanations!
First of all, this file is just Ruby code (see the
.rb) using some new methods that are available through the minitest framework. The
require 'test_helper' in the first line is what gives this test file (
test/controllers/static_pages_controller_test.rb) all the methods and setup it needs to be run by minitest properly when you run your test suite (e.g. by typing or
$ bundle exec rake test on the command line).
When you run the test file, mini stores each
#test block as a separate test and then runs them in a random order (which is important to make sure you haven’t accidentally caused one test to influence another). So all the stuff inside the
#test block is what’s actually passing or failing if you run the test.
It’s also important to note that each test is completely independent of every other test. Your test database gets completely reset each time it moves on to running another test, then minitest starts from the top and runs the next test. You should be able to see why that is important – a test wouldn’t be very useful if it got polluted by what your other tests were doing.
The first test (inside the block for the
#test method) has just three lines. The first,
get :home, is just a necessary step to get you into position to run the test. Because this is an extremely simple test file, that is inside the
#test block. If you ended up running multiple specs that relied on visiting that same page first, you’d see that line abstracted out into a
#before block, which would be run before each test.
The second line
assert_response :success, makes sure that the home page returns an http status code of 200 or in other words success. The third line
assert_select "title", "Home | Ruby on Rails Tutorial Sample App" is where the action happens.
assert_select "title" selects an element on the page—in this case the title element— and waits for some sort of definitive answer about whether the page passes or fails.
"Home | Ruby on Rails Tutorial Sample App" this is the expected value you are asserting the title will contain if the title matches this string the test will pass otherwise it will fail. You don’t actually need to know all the specifics of what’s going on behind the scenes for a while, just how to apply them.
If you’re already scratching your head, don’t worry (like I said, better explanations exist than mine). The tutorial will cover testing along the way. Hopefully your mind is warmed up right now and you won’t be ambushed by suddenly being confronted with it.
This section contains helpful links to other content. It isn’t required, so consider it supplemental for if you need to dive deeper into something*