Intro to RSpec

Hello Sport and Tech lovers!

This week we're going to go over some of the tools we use internally for testing and the reasons behind it.

What's RSpec?*
A Ruby testing framework focused on Behaviour Driven Development. It allows you to test your Ruby code with a legible syntax and much more easily than if you were doing the same manually and repeatedly.

What will I learn during this meetup?*
- Why you should be testing your code.
- How to set up RSpec with Rails for API Testing.
- Learn how to write your first tests.

> Important: this talk will be conducted in English.

RSpec with a combination of other awesome gems has been used to build and test the Decathlon Sport Places API (http://developers.decathlon.com/sportplaces/) and others.

Transcript

1. Intro to RSpec How We Test Rails Applications
2. Who am I? Caio Bianchi Back-end Developer @ Decathlon Canada Github: @CaioBianchi Email: caio.bianchi@decathlon.com
3. How? The hardest part of being a beginner is that you often don’t know the terminology or what questions you should be asking. We’re going to cover the following tonight: • How to use it with Rails? • Useful Gems • What are Model Specs, Request Specs, Factories, Stubs etc…? • How to get started on testing an API.
4. How to use RSpec with Rails? • Include the rspec-rails in your Gemfile and run bundle install
 group :development, :test do gem 'rspec-rails', '~> 3.7' end • Rspec has a built-in initializer for rails: 
 rails generate rspec:install
5. Useful Gems • Database Cleaner • Factory Bot • Faker • Shoulda Matchers*
6. Factories • Factories are fixture replacements with a straightforward definition syntax, support for multiple build strategies (saved instances, unsaved instances, attribute hashes, and stubbed objects), and support for multiple factories for the same class (user, admin_user, and so on), including factory inheritance. • In other words, it’s a better way to generate fake/ testable data.
7. Stubs • Stubs are mostly used to record interactions with external requests. • Example: Recording an API call to Google Maps for testing so you don’t exceed your quota by testing over and over. • See: Webmock, VCR etc…
8. Model Specs • Model specs are similar to unit tests in that they are used to test smaller parts of the system, such as classes or methods. Sometimes they interact with the database, too. They should be fast and handle edge cases for the system under test. • In Rails, this will “describe” your data structure logic.
9. Controller Specs • Controller specs have been around since the early days of Rails and have historically been the way to test that web requests “do the right thing(s)”. • Controller tests while looking like they test the request behaviour actually do not — they test the implementation of the controller object.
10. Request Specs • Request specs are the way to test the behaviour of a request in a way that is much closer to the way the code will execute in a production environment. • We are testing the response to the actions, rather than testing object methods. (E.g.: #new, #show, #index etc..)
11. Which ones to use? • Request Specs are BETTER! • The use of Controller Specs have been deprecated in earlier versions of Rails. • Model Testing is still (very) useful when running a tight ship on the business logic of your application.
12. One more thing… • Other things worth looking at, that we’re not getting into tonight: • View Specs (if your application does SSR) • Feature Specs (For headless browser testing with Capybara)
13. Recommended Books • Rails 5 Test Prescriptions by PragProg (~ $25) • Testing Rails by Thoughtbot (~ $30) • Effective Testing with RSpec 3 by PragProg (~ $20)
14. Don’t be shy to ask for help! :) Hands-on and FAQ Afterwards.