In this course, we will be testing a simple command line card game using RSpec. We'll cover the core three libraries: the first module covers the core syntax and command line runner core, the second the expectation library for expressing rich assertions about your code, and the third covers mocks, a powerful tool for specifying collaborations between objects and getting useful design feedback. The final module places RSpec in the wider Ruby ecosystem, looking at the major RSpec versions and common patterns you'll encounter in the wild. In addition to covering the technical aspects of using RSpec, we'll also cover best practices for using them so you get the most out of your test suite: different types of tests, what kinds of things to test, when different styles are appropriate. This is applied in numerous worked examples.
Course Overview Hi everyone, my name is Xavier Shay, and welcome to my course, Testing Ruby Applications with RSpec. I'm on the core team for RSpec, the most popular Ruby testing library. RSpec was released in 2005 and has since matured into a fully featured and stable open source framework. In this course, we'll be building up a test suite for a simple command line card game. To do so, we'll be using the three main RSpec components. First, the core library, which contains RSpec syntax and the command line runner. It's all you really need to get started. Second, the expectations library will allow us to better express properties of our code rather than writing complicated checks ourselves. And thirdly, the mocks library, which allow us to easily create fakes for testing collaboration between objects and to get architecture design feedback on our code. We'll go through the when, why, and how of using each of them, covering testing best practices along the way. Before beginning this course, you should be familiar with the basics of the Ruby language. I hope you'll join me on this journey to learn RSpec with the Testing Ruby Applications with RSpec course at Pluralsight.
Getting Started Hello and welcome to this screencast, Testing Ruby Applications with RSpec. My name is Xavier Shay, and I'm a member of the RSpec core team. Over the next hour and a half, or so, we're going to be using the popular RSpec library to describe and test a simple command-line game, Lightning High Card. You bet on whether you think your hand contains higher or lower cards than your computer opponent. RSpec is one of the most popular testing libraries for Ruby. It provides a DSL for specifying the behavior of your application with executable code, so that you can have confidence your app works how you intend. RSpec is actually a family of libraries that you can pick and choose, core for the basic runner and syntax, expectations, matches and helper methods for expressing expected outcomes in your tests, and mocks for creating flexible test doubles. You'll learn all three in this course, roughly one per module. In the fourth and final module, we'll survey the wider RSpec ecosystem, history and plans for the project, how it relates to other testing libraries, using third-party plugins, and the like. This will all help you get the most out of your RSpec use. Throughout this course, in addition to learning about the features and mechanics of RSpec, I hope that you will also pick up some higher level concepts, why we test, how to decide what techniques to use, these will all help you use RSpec most effectively. I've been doing automated testing for a long time, so I have some opinions to share. Anyway, that's enough of an intro, let's quickly get your environment set up so we can get started on your first spec.
Understanding the RSpec Ecosystem Welcome to the fourth and final module of this screencast. I want to take a step back and look at the ecosystem of libraries around RSpec, including older versions. This will help you understand what you will likely encounter in the wild. To begin, let's look at some popular syntax that I haven't covered, the should syntax. These two snippets are equivalent, the expect version on the bottom is what we've been using in this course, the should version above is an alternative. The RSpec core team prefers the expect syntax since should has some weird inconsistencies. It requires monkey-patching every object in the system, which we can't do reliably, it generates Ruby warnings, and it also requires some odd code to deal with operator precedence. This should style is very common in all the code bases and tutorials, but as of RSpec 3, it now issues a deprecation warning unless you explicitly enable it. In RSpec 4 we plan to move the should syntax into a separate gem. Speaking of RSpec 4, RSpec strictly follows the principles of semantic versioning, which holds that backwards incompatible changes can only be made in major version changes, such as from 2 to 3. This means that you should always be able to confidently upgrade to a point release such as from 3. 3 to 3. 4, which was released just as I'm finishing this screencast, without fear of anything breaking. In the unlikely event that something does happen to break, we consider it a bug, and we'll get a fix release out as soon as possible.