Re:Stop requiring only one assertion per unit test: Multiple...
by fiddlerwoaroof on Saturday November 05, 2022 @12:43PM
(#33483107)
Well, Function.toString() should print the code of a lambda in JavaScript. So I think you could do it without a pre-processor: use Babel as a library to parse the body of the function; run each sub-expression separately and display the results.
Re:Stop requiring only one assertion per unit test: Multiple...
by tobyhinloopen on Sunday November 06, 2022 @04:31PM
(#33497447)
Can you actually do that, since you don’t have the context the function is running in?
You can inspect the source, but functions don’t run in isolation so you cannot extract the source and run it somewhere else.
Simple example:
var x = 0;
var y = function() { x++; };
Maybe if you replace the function with another by injecting code into a copy of the source, but I’m not sure if that’s even possible.
Re:Stop requiring only one assertion per unit test: Multiple...
by fiddlerwoaroof on Sunday November 06, 2022 @04:40PM
(#33497555)
You can just document a constraint that these function must use the purely functional subset of JavaScript, which is enough for the sorts of assertions I typically write. Alternatively, you could constrain it to the subset that has no unbound variables or side effects.
I like to use Jest’s toMatchObject to combine multiple assertions in a single assertion. If the assertion fails, the full object on both sides is shown in logs. You can easily debug tests that way.
The only way to make it even possible is to do some eval magic or to use a pre-processor like babel or a typescript compiler plugin.
But if you find something, Lemme know.