1. 8
  1.  

  2. 2

    I’ve definitely worried about “will this test pass for a trivial reason instead of the real reason” before, and often I try and resolve it by (for example) examining the description associated with the exception I caught, a notoriously brittle approach that adds test maintenance burden.

    This seems a much more sensible and robust solution, and I’m itching to find out whether it’s as practical and useful in large code-bases as it sounds.