Making Tests Work with RSpec and Capybara in Rails

This past weekend I worked on the next section which was Rails II – basically we were to build the project and utilize testing to make sure it would work. There were different levels one could do to complete this assignment: 1. Do the assignment without testing 2. Make the assignment work with the testing they provided on the platform or 3. Write your own tests in addition to the ones that were provided. This assignment was like a series, in which we add onto the project with each assignment we complete. We were given a wireframe and the tests and were set loose.

The project is to login or register a user, upon logon this page will redirect to the users Secrets page where a user can create their own secret, show the secrets they’ve liked or delete secrets they’ve created. There was a Secrets page which displayed all the secrets, allowed only the user logged in to like/unlike or delete the secrets they’ve created (much like the users’ show page). Along the way, we also implemented User Authentication (which is how we allowed only the logged in user to navigate through the app)

It turns out it’s as easy as putting a method at the top of our UsersController:

before_action :require_login, except: [:new, :create]

The above code states that before you do anything, go to the require_login method which verifies if the user is indeed the user that’s logged in via the session[:user_id] variable. The exception in this case is the new and create methods — A user should be able to access the page to create a new session by logging in or registering as a new user.

In the Secrets Controller, we added this code:

before_action :require_login, only: [:index, :create, :destroy]

Which states that before you go to any method, make sure that the user trying to access the page is indeed the user that’s logged in (as above) and if not, redirect that person back to the page where they can create an account or login. In the only:  tag, we allow only the logged in user access the index, create and destroy methods. We created tests for these methods.

Next up is the User Authorization. This is the code that’s put at the top of our UsersController:

before_action :require_correct_user, only: [:show, :edit, :update, :destroy]

The require_correct_user is used to define if the user is the one logged in and if not, redirects that user to their own page so they aren’t able to view everyone else’s pages…here’s the method defined in the application_controller:

  def require_correct_user

    user = User.find(params[:id])

    redirect_to “/users/#{current_user.id}” if current_user != user

  end

The last part of this section was to create our own tests for the User Authorization and User Authentication. I’ll leave you with some snippets of my tests:

likes_controller_spec

likes_controller_spec_2

TDD with RSpec

The end of last week was spent doing Test Driven Development with RSpec. The idea of test driven development is to test each feature in a project, fail that test, write code that makes that test pass, repeat. Each method, each feature should be tested to ensure it works correctly.

RSpec is one of the most popular testing frameworks in rails. It can create instances of your controllers, models and views and test them, it tests whether the routes are set up properly, it tests that the request and response is received from the server and tests regular Ruby classes…It’s pretty powerful tool to have.

We used expectations in the Coding Dojo console. Mainly, expect and to…meaning expect(page).to have_text(“The Dog”) which translates to expect the page to have the text “The Dog” on it, of course this after an action has been made. It’s pretty cool that it translate to plain English.

Then there’s the describe method which is used to list what the controllers and methods are supposed to do, for instance you can ‘describe’ a CodingController by saying that ‘it’ should show all coders. When describing Controller classes and methods, you should always put in require ‘rails_helper’ so it can find the controller or method you wish to describe. We also testing the models to make sure the validations and relationships were working properly.

We were introduced to Capybara which tests the actual user expectation when visiting a page for example you can declare statements like these ‘visit “/coding/new”, fill_in ‘New’, :with => “Tiffany”

And finally we testing for features of the page for example it “prompts the user fields”

After a few assignments, I cruised to the next section.

Controllers and Views in Rails:

This post is long overdue! We learned about Controllers and Views last week.

If you do something like this to make a new controller: rails g controller products index new

this is what’s called rendering by default what this means is that the method will attempt to load a view by the same name of the method (Rails automatically creates a view when you create methods in the Controller). The only way to prevent this behavior from happening is to render another view or redirect to another method.

To render another view: Specify using ‘render filename’ or ‘render folder/filename’ – if it’s in a different view folder. If a user registers to your page and the registration failed, then you want to render a page, this allows the page to display an error message and doesn’t save anything to the database. Rendering allows the error message to be displayed in an @instance_variable to display the view page.

The second option is redirect_to: redirects the browser to another controller/method…sends another HTTP request. redirects_to doesn’t actually load another view, it calls another controller/method to render a view. Use redirect_to when a user logs into your site and redirect them to another page because you don’t want to submit an HTTP request.

After a render and redirect_to: the code after those statements are ran.

render: works the same as var_dump and die() that we used in PHP

Passing variable to the view in Rails: Just put an @symbol in front of the variable name in the Controller that you want to make available in the View.

I completed a few assignments to day: All were pretty simple – straight the point. Most notably the Random Name Generator and the Survey Form all which we have done before in different languages so once you’ve seen it once, it’s pretty easy to tackle. Plus, these assignments are merely to get our feet wet in the language and be comfortable assigning instance variables, session data and flash data plus being about to show information in the views.

Social Good + Technology = Happiness for All

I recently went to a Holiday Meetup Mashup sponsored by ThoughtWorks in Dallas that was centered around the idea of bringing social good and technology together to create helpful solutions to issues.

The event began with you signing in and grabbing your pre printed name tag if you RSVP’d, they also suggested everyone put a star sticker on their name tag with a color to indicate if you are a non profit in need of help (red), a technologist who can offer help (green) or whether you were there to enjoy the event (gold). I thought the process made it easier for everyone to be identified.

There was an hour of social/networking time before the eight lightning talks began. The talks varied from specific non profits speaking on how they needed help to developers who have helped non profits and continue to do so.

I especially enjoyed the talks given about The Texas Parks and Wildlife and <Bold Idea>. The parks and wildlife talk wanted to bring together technology and the outdoors since most kids are on their electronic devices. The speaker wanted to marry to two ideas together. <Bold Idea> needed volunteers and developers to help mentor kids who enjoy tech. The idea is to hone in on their skills while they are young so they have a healthy exposure to it at an early stage in their life.

After the lightning talks, it was networking time. I also had a chance to speak to the organizer of the event and give feedback and connect with some people in the non profit industry who needed tech help. They also had a wall where you can add your contact info to a post-it note and tag it on the wall and those who needed help can put there info as well so we could connect. I thought it was brilliant, especially if you were in a hurry.

The event ended when you put your name tag into one of three buckets to indicate how you enjoyed the event: Enjoyed it, somewhat liked it or hated it. I sneaked a peek and found that most enjoyed the event.

I plan to get involved with mentoring in the <Bold Idea> project and see if I can come up with some ideas for the Texas Parks and Wildlife. Oh, and organizer mentioned they wanted to schedule a hackathon in the near future, can’t wait for that!

All and all, the event was awesome and I look forward to many more!