Format events as json

[ijc]

I'd like to be able to make assertions about the contents of the logging when encoded to json. Would it be possible to support this? Perhaps #[traced_test(json)] or something like that could be made to work?

Might be a bit related to #5?

[dbrgn]

Can you give a concrete example?

One way how this might be achieved is using the new (in 0.2) logs_assert function that's injected into your test function. You get access to a slice of logs, and can do whatever you want with it in order to validate the contents. For example, you could write a helper method and then call logs_assert(my_json_content_assertion); in your test.

[ijc]

We are using structured logging and have other systems which will expect certain fields to exist so I would like to validate we were really generating them in the expected JSON object structure.

I think logs_assert currently gives me the plain-text/non-json logs (fmt::format::Full I think?). If it gave me the json encoded string I could happily parse it to perform my checks. I think to enable that get_subscriber would need to gain a conditional .json() in the builder chain.

[dbrgn]

Ah, I see what you mean. Yes, this is most certainly related to #5. I'm not familiar with the .json(), but that might actually be a way to implement #5 if it's supported out of the box.

[ijc]

I could have been more helpful and linked to .json() which switches the subscriber to fmt::format::Json.

As well as injecting the .json I suspect the matching in logs_with_scope_contain would need to adjusted since it won't match anymore.

As an alternative to a macro option I think a crate level feature would be ok too if that simplifies things

[dbrgn]

I'd welcome a generic solution that switches internal log record storage to a more structured format (i.e. #5). I think with that, we wouldn't need a JSON option, because it would already allow accessing structured fields. This might be implemented through JSON though.

If all structured records would be accessible when doing assertions against logs, would that solve the issue for you? If yes, would you be OK with closing this issue in favor of #5?

[ijc]

Yes, I think I could live with that.

I'd like to be able to test the serialisation side of things, but that could as well be separate/unrelated test.