1

I have written up a series of integration tests for a set of web apps using WebDriver, JUnit and Drone. I am now in the processing of removing the System.out.println commands that display information about the current status of the integration test at key points and would like to replace some of them in a way that does not reduce performance as much as System.out.println. Currently I am using a Logger and logging key points with Level.INFO, while I log exceptions that affect the test with the Level.WARNING and level.SEVERE options. Assertions handle most of my logging.

As I am an inexperienced programmer and very new to logging, I was wondering the following:

  • Is there a set of conventions for logging levels (more specifically what to log with INFO levels)?
  • From my description, have I got a grasp of how Loggers should be used?

An answer regarding this situation (integration testing) would be much appreciated, as I believe I'm aware of logging within an application.

1 Answers1

0

with integration tests that must be accounted is the use of detailed logging. When a unit test fails it is very easy to understand why since the scope is very narrow. When an integration test fails, things are not so simple.

Because by definition an integration tests is based on many components and a specific data flow, identifying the failure cause is not always straightforward. [1]

And about which level of log for which information :

  • Trace - The finest logging level. Can be used to log very specific information that is only relevant in a true debugging scenario, e.g., log every database access or every http call etc.
  • Debug - Informartion to primary help you to debug your program. E.g., log every time a batching routine empties its batch or a new file is created on disk etc.
  • Info - General application flow, such as "Starting app", "connecting to db", "registering ...". In short, information which should help any observer understand what the application is doing in general.
  • Warn - Warns of errors that can be recovered. Such as failing to parse a date or using an unsafe routine. Note though that we should still try to obey the fail fast principle and not hide e.g., configuration errors using warning message, even though we a default value might be provided by the application.
  • Error - Denotes an often unrecoverable error. Such as failing to open a database connection.
  • Fatal/Critical Used to log an error the application cannot recover from, which might lead to an immediate program termination. [2]

I hope this merge if these 2 good answers will help you.

[1] : http://zeroturnaround.com/rebellabs/the-correct-way-to-use-integration-tests-in-your-build-process/

[2]: Stackoverflow : What information to include at each log level?

Community
  • 1
  • 1
Valentin Montmirail
  • 2,594
  • 1
  • 25
  • 53
  • Okay, thank you. So most of my Error/Fatal/Critical problems are logged by JUnits assertion failures. If I understand correctly I can use the INFO level of logging to state things like "Successfully executed i with values j and k" at key points in my test? For things that are easily remedied, like changing the file path/ name of a file to be uploaded is it appropriate to log a Warning, throw a more general exception and then fail the test with a more severe level of log? –  Aug 04 '15 at 11:18
  • You get it :) that's how it work, however is not a real convention, and your question is an open question, logs are like an interpretation... :) But let's say if you try to follow theses rules, your logs will make sense :) – Valentin Montmirail Aug 04 '15 at 11:20
  • 1
    I did look at the zeroturnaround article but I didn't find it too helpful. Thanks for the concise answer! –  Aug 04 '15 at 11:22