-
Notifications
You must be signed in to change notification settings - Fork 28
@expectedFailure decorator should result in # TODO directives #74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@smcv thanks for the report. I made the decision when I started the project that I would strictly stick with the TAP specification to be as consistent as I think is reasonable. Since unexpected success and failure is not part of the TAP spec for version 12 or 13 (I checked again just now to confirm), then I think my call is to continue to exclude this functionality from tappy. If this kind of feature is included in future versions of the spec, I'm happy to include it then. You might want to comment on the proposed TAP 14 spec to see if it makes sense to include it. TestAnything/testanything.github.io#36 |
The spec calls it a "TODO test", but I'm fairly sure it's the same thing as Python
which sounds a lot like |
Sorry, maybe I got confused about what you are looking for specifically. My apologies for a premature closure. I was being very myopic (which may be because I'm reading in spare minutes at PyCon) and thought that you were looking for an expected failure to report as I hacked in an
but instead got
which is probably what you were trying to point out from the beginning but I was being too slow. I agree with your interpretation of the spec. There should be a Sorry for the misunderstanding! 😇 P.S. I thought it already did this. Thanks for pointing it out. |
This aligns better with the specification. > These tests represent a feature to be implemented or a bug to be fixed and act as something of an executable “things to do” list. They are not expected to succeed. Fixes #74
Sorry, no, the text given in my example was from the Perl equivalent of a hypothetical
in Python (but unfortunately expectedFailure doesn't currently support giving a reason anyway). You are correct to say that what I wanted was the addition of a |
* expectedFailure should be treated as a TODO. This aligns better with the specification. > These tests represent a feature to be implemented or a bug to be fixed and act as something of an executable “things to do” list. They are not expected to succeed. Fixes #74 * Update the release docs. * Try to fix brew.
Other TAP producers, such as Perl, report expected failures and unexpected successes like this:
Here test 1 is an expected failure, and test 2 is an unexpected success (it was marked as an expected failure but succeeded anyway).
@expectedFailure
currently prints_('(expected failure)')
or_('(unexpected success)')
. If it printed# TODO
first, resulting in something likethen that would interoperate with other consumers.
The text was updated successfully, but these errors were encountered: