Test Driven Development

The “Grammable” applcation marked the first experience that I had with Test Driven Development. Grammable is a site similat to Instagram. It’s a mock site that allows users to upload images and make comments about them. The entire application was built using TDD. Take a moment to check out the site and then we’ll dive into specifics.

What is TDD? Simply put, TDD is writing test code (in plain english) to test the actual code in your software, to ensure that everything passes before you push it to production. It also serves other purposes, that I will get into in a bit.

As you first start to build Web Applications, the process goes something like this — and it’s a bit archaic.

  1. Start writing some code in your editor — here’s a simple landing page.

2. Open your browser to make sure that it worked -

Ok cool, that worked because I had to check to make sure. And you can see where I’m going with this…as the application gets larger and larger, you get carpo-tunnel going back and forth to make sure that your changes were implemented and work! There has to be a better way!

Enter TDD. During the production of Grammable, I think I looked at the web page itself maybe twice in development and once on the production side (just to make sure my commits got pushed to the server), even though in reality I didn’t need to. All of the styling was done for the application once the core features were implemented. Typically you would implement a feature, style it and then move on.

How does TDD work?

For this project, I used two Ruby Gems. RSPEC and FACTORY_GIRL. They get loaded into your Gemfile, then you perform a $ bundle install in your terminal.

Once you have it installed, you get your test suite configured by following the documentation on GitHub: https://github.com/rspec/rspec-rails

Advanced Test Usage

One of the back end features of Grammable, is to allow users to make comments on images that are uploaded. Here’s a screenshot of the front-end form:

There’s one comment from golfer@yahoo.com on Rory McIlroy’s new sticks for 2017! Plus there’s a box to add a comment and a button to submit your response.

So what went into all of this? We want a few things for our comments to be applied to the site -

  1. Allow users to make comments
  2. Require that they be logged in, or else they get re-directed to the sing-in / sign-up page
  3. Have the site return an error if someone tries to make a comment on a “Gram” that isn’t present (yes hackers try to do this to break your site).

RSPEC and FACTORY_GIRL

The RSPEC and Factory_Girl tests in the editor are very close to the way that we described them above (plain english). Have a look — FYI (FactoryGirl lets you create mock users and mock data for running test suites — beats testing it yourself )

If you follow along to the test the first case is….”It should allow users to create comments on grams”. The next test is “It should require that a user be logged in” OR they get redirected to a new_user_session_path (programming speak for “log-in”). Third test, “It should return and error if the gram isn’t found.

So once you have these tests written, you run a $ bundle exec rspec in your terminal —

And survey the results….

Seems we have a test that failed here from our test suite. It’s telling me that it expected to be re-directed to the root_path. Now I omitted some code here for this example. If you count the green dots above the suite is runing 23 tests and we had 1 F (fail).

If we look at the code that makes this happen on the application side (app/controllers/comments-controller.rb)-

I commented out line 5 of the CREATE method to get the test to break, but this is exactlly how TDD works.

  1. You write a test
  2. Run the bundle exec rspec and get it to fail (No code written yet)
  3. Go add the necessary code
  4. Re-Run the tests until you to get it to pass.

I’ll fix the code here…..and re-run the test -

So imagine a product like Facebook or Twitter. There are hundreds if not thousands of Developers working on improvements at any given time. Tests like these ensure -

  1. That you know what is being tested (plain english tests right?)
  2. That new features are working correctly

AND THE MOST IMPORTANT

3. That you don’t break previously working features.

This beats clicking on every link in your application to make sure things work. Once command and I get the results of the test suite.

Back to programming, until next time!