Gennadiy Rozental writes:
Expected failures look like failed unit tests where the number of failed assertions is _less_ than expected.
Boost.Test "Expected failures" feature allows developer to specify that specific test case supposed to have this number of failures (IOW developer knows about the issue and doesn't want test case failure to be reported for now). Any other number of assertion failures (more or less) cause test case to fail. Be aware though: unless you are using TDD practice of one assertion per test case it could be quite dangerous to use this feature on permanent basis.
Yes, that's more-or-less what I had in mind.
Consider what will happened when after your change once assertion that supposed to fail is not failing anymore, while another one that shouldn't does? Most probably you will never notice that (since the test case will pass). So use it with caution ant preferably for temporary
Precisely. I suppose maybe we could state on an assertion-by-assertion basis which ones are expected to fail, but I personally think that's overkill. :-) I haven't really decided how to use the Boost test library yet, and am very open to suggestions. Also see my reply to Robert Mathews. And, of course, thanks for the library! ---------------------------------------------------------------------- Dave Steffen, Ph.D. "Irrationality is the square root of all evil" Numerica Corporation -- Douglas Hofstadter Software Engineer IV "Oppernockity tunes but once." -- anon.