to implement the test. What’s especially convenient about this is that only the second element (the step) is dependent on the implementation, so that if we change, for example, the CSS class used for error messages, the feature file would stay the same.
             In this vein, it might make you unhappy to write

in a bunch of places, when what you really want is to indicate that the page should have an error message. This practice couples the test tightly to the implementation, and we would have to change it everywhere if the implementation changed. In the context of pure RSpec, there is a solution, which is to use a custom matcher, allowing us to write  the following instead: 

We can definesuch a matcher in thesame utilities file where we put the full_title test helper in Section 5.3.4. The code itself looks like this: 

We can also define helper functions for common operations:

The resulting support code is shown in Listing 8.34 (which incorporates the results of Listing 5.37 and Listing 5.38 from Section 5.6). I find this approach to be more flexible than Cucumber step definitions, particularly when the matchers or should helpers naturally take an argument, such as valid_signin(user). Step definitions can replicate this functionality with regex matchers, but I generally find this approach to be more (cu)cumbersome.