Tag Archives: Test Log

And Thereby Hangs a Tale

Your test log should tell a story — the story of what the test did.

When a verification fails, you should be able to learn a great deal from the log itself, without having to go back to the test method’s code.

Most test loggers are flat, with all entries at the same structural level. This makes it difficult for anyone reading the log to understand the test’s structure and intent.

To make the story’s flow obvious, organize your test log into sections and subsections, each with a title. These sections need to be evident both in the test method and in the test log.

The key concept here is that the in the test code, a statement starts a section that will end when something goes out of scope. The statement itself begins the section, and the going-out-of-scope ends it.

How to implement? That depends in part on the language. Examples:

  • Ruby:  block.
  • PythonWITH statement.
  • C#: using statement with IDisposable.

I’ve written test loggers in all three of these languages (plus Perl), and will share more details with interested parties.