Neal Norwitz wrote:
> All the expect methods duplicate the assert methods. Asserts can the
> test to fail immediately, expects don't fail immediately allowing the
> test to continue. All the expect failures are collected and printed
> at the end of the method run. I was a little skeptical about assert
> vs expect at first, but it has proven useful in the long run. As I
> said, I don't think this should be done now, maybe later.
I'd agree these kinds of things can be very useful, particularly for
tests which run the same test for multiple inputs - when those tests die
on the first set of input values that do the wrong thing, it greatly
slows down the test-fix-retest cycle, since you have to go through it
multiple times. If the test is written to test all the input values,
even if some of them fail, and then report at the end "test failed, here
are the (input, expected_ouput, actual_output) that didn't work" it can
make tests far more efficient.
At the moment I do it manually by collected a list of failed triples,
then reporting a test failure at the end if the list isn't empty, but
something like "expect" methods would avoid the need to recreate that
infrastructure every time I need it.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4