From: Dave Steffen (dgsteffen_at_[hidden])
Date: 2005-04-06 10:27:20
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.