140 Testing basics [3.5d]

Goals

• Understand why we test:
  • Low defect rate without a QA department.
  • Customer acceptance testing can concentrate on new features and things a robot cannot do (e.g. how does a feature look and feel).
  • Frequent deploy gets changes to users faster.
  • We sleep better, because we know stuff still works.
  • Make sure no one removes a feature by accident.
  • Ability to change one part of an application without needing to understand the entire system.
• Why do we use different types of tests?
  • What are the pros and cons of unit tests?
  • What are the pros and cons of end-to-end tests ("E2E tests", "full-stack integration tests").
• Learn basic RSpec for unit tests ("model specs") and E2E tests ("features")
• Learn to use Capybara Show archive.org snapshot to control a browser from your test script
• Understand the disadvantages of too much testing.
  • Writing tests costs time.
  • Tests must be maintained when the application changes.
  • The more tests you already have, the less useful an additional test becomes ("Diminishing returns").
  • Tests sometimes fail even though the code is fine, especially when the test is coupled tightly to the implementation.
• Learn how to run tests in existing applications.
  • Learn about Geordi Show archive.org snapshot 's rspec and tests commands
• Learn when to write unit tests, when to write integration tests, when to write both.
• Understand why we rarely write controller or view specs.
• Understand the old RSpec "should" syntax Show archive.org snapshot
  • You should be able to write both with "should" and "expect"
  • You should know how to enable the old #should-syntax in RSpec 3 Show archive.org snapshot
• Understand what "Test the behavior, not the implementation" means.

Resources

• Chapter "The value of tests" from Growing Rails Applications in Practice Show archive.org snapshot (in our library)
• Everyday Rails Testing with RSpec Show archive.org snapshot (in our library Show archive.org snapshot )
  As of today, the Rails 7 version of this book is not fully complete. Until then, we have to work with two versions. Concentrate on chapters:
  • 1 (Introduction), 2 (Setting up RSpec), 3 (Model specs) and 4 (DRY enough specs) from the Rails 7 version
  • 6 (Feature Specs) and 9 (Writing tests faster, and writing faster tests) from the Rails 5 version

Your MovieDB already comes with working RSpec examples.

Exercises

Play with existing tests

In one of the sample apps that are using RSpec feature specs

• Run unit and integration tests. All tests should pass.
• Find an RSpec unit test and break an expectation. See what happens when you re-run the test.
• Find an RSpec feature test and break an expectation. See what happens when you re-run the test.

Your first E2E feature

• Write a feature test for CRUDing movies in your MovieDB application.
• Use Capybara to talk to the simulated browser.

Unit vs. Feature testing

Add the following feature to MovieDB:

• Above the movies list is a text field and a button "Search"
• When the user enters text into the text field and hits "Search", the movies index is filtered to only contain matching movies

Some hints for the implementation:

• Your Movie model should gain a class method Movie.search(query) or even better a scope method you can apply to the scope in the controller. Why should this not be an instance method?
• You can implement the search in either SQL or Ruby
• The form_for helper is not helpful for the search form above the index. Why is that so? What can you use instead?
• Add a custom route /movies/search to your routes, and map it to a new #search action in MoviesController
• Try to reuse some of the existing private methods for the implementation of #search
• When rendering search results, try to reuse the existing index views, or at least large parts of its.

Now add tests for both the new method Movie.search() and the new UI.

Follow the advice from the "Testing" chapter from Growing Rails Applications in Practice Show archive.org snapshot :

• RSpec feature tests for the most common "happy path"
• RSpec unit tests for all the edge cases (like case insensitivity)

Future exercises

When doing coding exercises in future cards, always deliver tests together with your implementation.