Comment by dkarl

You can get half the benefit, including all of the readability benefit, from two much more accessible factors that can be achieved in most languages without much additional work, and will make your production code more readable to as well:

— Most of your code, including virtually all of your complex code, should be functional in style, so that you can test each case by checking the return value.

— You should be able to represent expected return values literally in code.

The first is important so that you don't have to use mocks to test side effects. Mocking is an important technique when you need it, but it's always better if you can avoid it.

The second is important so that you get a simple readable equality comparison between two values, instead of needing to build up the expected value imperatively and/or write multiple statements to interrogate different aspects of the return value, which is less readable and more mistake-prone.

If your code follows these two principles, you get all the conciseness and readability shown in this demo, but you don't get the expected values automatically filled in for you.

If you have one more thing, for which you'll probably want language support or you won't bother with it, you can at least copy the value from the test failure and paste it in yourself:

— The default way that data is stringified is a literal representation that can be pasted into your code.

It's very cool and very impressive the way they've combined these factors and built tooling to make such a slick workflow!