Allow multiple message arguments in assertions?

[billyjanitsch]

Description

I've found t.log extremely useful, especially in how it formats React elements and test renderer output. I often write code like:

t.log(actualComponent, 'did not match', expectedComponent)

Unfortunately there's no way to pass this sort of message to an actual assertion, since they only take a single message argument. If I use a template string (${actualComponent} did not match ${expectedComponent}) then I lose AVA's fancy formatting. I have to choose between passing a string or a single object to be nicely formatted.

This seems like a pretty limiting restriction. I wish I could do stuff like:

t.notThrows(() => doSomething(foo), foo, 'did not do something')

Was there a particular reason to only let assertions take a single message argument?

[sindresorhus]

Was there a particular reason to only let assertions take a single message argument?

Simplicity. Having variadic parameters makes the assertions hard to read. We could consider supporting an array as an argument or having a t.format() method you pass to it.

[novemberborn]

We have #1125 which enforces message to be a string. I just realized we should try and land that for 1.0.

We could consider supporting an array as an argument or having a t.format() method you pass to it.

I like the idea of having a function that does the formatting and returns an object that is recognized by the assertions. Perhaps not on t though. How about test.message(any, 'possible', argument, 'like t.log')? And then t.is(true, false, test.message('hello')? t.log() could also accept this value.