It does deliver value because it allows you to document the context of the assertion code in a way that's more enduring than a comment, and in a way that's visi

It does deliver value because it allows you to document the context of the assertion code in a way that's more enduring than a comment, and in a way that's visible at failure time. I actually use a homebrewed assertion context specifier, where I wrap blocks of code in a "that" context, which then decorates any thrown exceptions. When your tests grow past verifying that string concatenation of your string class works (short, sweet, tight unit tests), and you end up testing business logic, you end up with tests that are just not that short and assertions which are not single-minded assertion. Often times you end up writing multiple asserts for one logical "assertion result", e.g. assert that returned map not null, map contains expected key, value for the key has correct detail, etc. Providing a single intent reason for a group of assertions is very helpful. Sometimes when time is tight, you might end up extending an existing test to assert one more concept instead of breaking it up into two separate tests. Now you can provide separate context for that assertion, and having the code be in a separate closure/block helps isolate it too. Note, that this is altogether different than the concept of writing tests by non-programmers (e.g. Cucumber).