Your Turn
In this chapter, you’ve seen how to slice and dice your specs by just about any way you can think of. You can run just the fastest examples, or the ones for a specific platform, or the ones you’re focusing for a particular task. The result is that you spend less time waiting for your specs to run, and more time writing code.
We’ve also peeled back the curtain to show you that the magic behind this flexibility is an ordinary Ruby hash. You can easily define cross-sections of your specs to fit any situation.
Now, it’s time to put this newfound experience to the test.
Exercise
When we are trying to find bottlenecks in our specs, we often look at SQL operations, one of the main sources of test slowness. It can be really useful to know which SQL statements came from which examples. With your knowledge of how metadata works, you can configure RSpec to report this information.
In Isolating Your Specs Using Database Transactions, you tagged several examples with the :db metadata to indicate that they use the database via the Sequel library. In this exercise, you’re going to modify RSpec’s behavior based on this metadata.
First, open spec/support/db.rb and add the following lines to the before(:suite) hook:
| | FileUtils.mkdir_p('log') |
| | require 'logger' |
| | DB.loggers << Logger.new('log/sequel.log') |
This code will configure Sequel to record each executed SQL statement to the log file.
Now, use the techniques from this chapter to make sure Sequel also writes the example descriptions into its log:
- Before each example runs, write: Starting example: #{example_description}
- After each example runs, write: Ending example: #{example_description}
Hint: DB.log_info(’some message’) will write whatever text you need into the Sequel log.