caplog: add convenience last_message property or messages?

[wcooley]

While refactoring, I noticed in a number of my tests which use caplog a common pattern of doing something then asserting something a pattern match for the very last log message, then doing something else, asserting something a pattern match for the very last log message, etc.

I created a helper function called last_message that just calls caplog.records[-1].getMessage().
That leads me to wonder if it would be useful enough to warrant LogCaptureFixture growing a last_message property?
Or, perhaps, an iterable messages property, which iterates through caplog.records calling getMessage() on each?
The difference between this and caplog.text.splitlines() is that log events can span lines (log.exceptions); caplog.records generally needs to have getMessage() called to get an actual string with formatting expanded.

Either is pretty simple; here are some untested implementations:

1. messages returning a list, so caplog.messages[-1] is sufficient for the last message:

   @property
   def messages(self):
       return [r.getMessage() for r in self.records]

2. messages returning a generator plus a last_message because list(caplog.messages)[-1] isn't so nice:

   @property
   def messages(self):
       for r in self.records:
           yield r.getMessage()
   
   @property
   def last_message(self):
       self.records[-1].getMessage()

Would there be interest in a PR adding one of these?

[pytestbot]

GitMate.io thinks a possibly related issue is #3406 (caplog documentation is incorrect).

[nicoddemus]

Hi @wcooley,

Thanks for writing.

I think the suggestion makes sense and a good fit. I would go with 1 because it fits along with records returning a list.

Would you like to contribute a PR? 😁

[nicoddemus]

Closed in #3585, thanks a lot for the PR @wcooley and welcome to the team! 👍 😁