Allowing multiple assertion failures per test
See original GitHub issueA mechanism for having multiple failures per test. In other words, an assert
failing wouldn’t result in a fail-fast for that test. Any remaining assertions would execute, and they’d all be displayed.
https://github.com/darrenburns/ward/pull/256#issuecomment-869049499
The interface is still undecided, but I would like to see this be configurable down to a per-test, and possibly even a per-assert level.
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Stop requiring only one assertion per unit test
One way to handle this is to refactor the test code into a method that can then be shared between two separate tests....
Read more >Is it OK to have multiple asserts in a single unit test?
The main reason people like to have multiple Assertions is they are trying to have a one [TestFixture] class for each class being...
Read more >Multiple Asserts | NUnit Docs
Multiple assertion failures per test are stored in the representation of the test result using new XML elements, which are not recognized by...
Read more >Multiple assertions per test may actually be OK - Corey Cleary
This is a case where having multiple assertions per test is valid, because you are testing properties of the object. Now, you might...
Read more >Multiple assertions are fine in a unit test - Hacker News
The entire job of an assertion is to wave a flag saying "here! condition failed!". In programming languages and test frameworks I worked...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thanks for the feedback!
I like the ideas around using the assertion message and about agree about making it a plugin.
I agree that this might be a little too “magical” for the core lib. That, combined with the fact that it’s not going to be a use-case everyone needs, means that a plugin is probably the best place for this. In this way, you could “opt in” to the magic where it offers value.
Good point about the messages!
If it’s part of handling the assertion message, I wonder if this behavior can be deferred to a plugin? Then the core library just needs to expose a general purpose
on_assertion_failure
hook that can decide whether to end the test or not flexibly.