Hitting the database isn't inherently bad. The issue is that it's slower than not hitting the database, so it's good to avoid it where practical. But when we're testing SQL queries, unless we're actually hitting the database, we're not really properly testing them. For example, with a test like this I might unwittingly add a typo in my query:

```ruby
  Token.delete_all ["action <> 'feeds' ANDOHNO created_at < ?", Time.now - @@validity_time]
```

Simply testing that there is a string there doesn't catch those kinds of typos, or confirm that our query is going to return the results we want. Here's another way of looking at it. The best way to test code is by running that code and checking the result. Typically, we're testing ruby code, so in cases like that we want to avoid hitting the database because that just slows our tests down. In cases like this where we have fragments of SQL code, the only way to properly test them is to execute them, and the only way to execute them is by hitting the database. If we had another method called 'my_method' that was calling `destroy_expired` then we would probably want to stub the `destroy_expired` method when testing `my_method` so as not to hit the database needlessly.