chewbranca commented on code in PR #4483:
URL: https://github.com/apache/couchdb/pull/4483#discussion_r1175832510
##########
src/couch_log/test/eunit/couch_log_formatter_test.erl:
##########
@@ -25,6 +25,22 @@ truncate_test() ->
Entry = couch_log_formatter:format(info, self(), Msg),
?assert(length(Entry#log_entry.msg) =< 16000).
+format_report_etoolong_test() ->
+ Payload = lists:flatten(["a" || _ <- lists:seq(1, 1048576)]),
+ Resp = couch_log_formatter:format_report(self(), report123, #{
+ msg => Payload
+ }),
+ ?assertEqual({error, emsgtoolong}, Resp).
+
+format_report_test() ->
+ {ok, Entry} = couch_log_formatter:format_report(self(), report123, #{
+ foo => 123,
+ bar => "barStr",
+ baz => baz
+ }),
+ Formatted = "[foo=\"123\" baz=\"baz\" bar=\"barStr\"]",
Review Comment:
@iilyak hmmm... so I specifically wanted to avoid needing to sort the keys
in the output string and to rely upon a fixed formatting, but you're correct in
pointing out that our test expects a consistent output.
Again, I don't want to sort the keys in the report for the normal use case
just to get a specific test result. The "fix" that jumps out to me would be to
dissect the resulting output string and assert the expected keys. For instance,
we could first regex pattern match on `^[` and `]$` to assert the formatted
output is in brackets. Then we could split the inner string on spaces, sort the
output, and then assert each of the key/value pairs matches up. I'm somewhat
inclined to leave this and see if we encounter it as a problem down the road,
but I think the approach I just outlined is viable if folks want to avoid that
eventuality. Alternative solutions welcome too 👍
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
