.

And if you could could go ahead and get a can of pesticide and take care
of the roach problem we’ve been having that would be great.

While as a general rule testing log output can make tests brittle because logs are free text and can change easily, there are certainly cases where testing them makes sense.

Our application was missing some really important business flow logging that we discovered was needed when we attempted to troubleshoot a production issue. We had to spend a significant amount of time hunting something down that would have been trivial to find in a well formatted info log message. I added that logging to the application and then wanted to make sure these business level log messages were being emitted at the right places in the application.

To test log messages in Padrino, I added the following helper to our spec/support/spec_helpers.rb file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# Pass a block and log output will be captured in that block and
# returned as an array of lines for testing.
def capture_logger_output
  logger.flush
  # This causes messages to be captured in the internal logger array
  # that can be accessed via logger.buffer.
  logger.auto_flush = false

  # Run user's code
  yield

  # Save the log lines captured during the test block
  # NOTE: have to clone otherwise flush clears the referred to array
  buffer = logger.buffer.clone

  logger.flush
  logger.auto_flush = true

  buffer
end

Now in your tests you can run test code and capture any log messages that happened during the code run!

1
2
3
4
5
6
7

it should test something do
  messages = capture_logger_output do
    post %{/to/some/url}, params, set_csrf
  end
  expect( last_response.status ).to eq 200
  expect( messages.select{ |line| line =~ /general match/ }.first ).to match /specific-pattern/
end

Happy log testing!