-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
TST: Fix assertNotIsInstance msg #13091
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
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need our own here? Nosetests has a pretty reasonable one:
(...although not as reasonable as pytest...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we define everything already so you can either do:
self.assertIsInstance
ortm.assertIsInstance
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, makes sense.
General marketing of pytest: in pytest you can just do
assert isinstance(x, x)
, and it writes the error message, which is all nice and pythonicThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MaximilianR of course everyone likes
pytest
better. I have used it for years. But changing would be a bear, not sure if its worth it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah.
How dependent is the testing suite on nosetests, vs just unittest?
We were using nosetests, moved to pytest, and it worked really seamlessly. But that's because we were really only using nosetests as the runner, rather than any nose-specific features
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would work right away. But, the power if
pytest
is really using fixtures, parameterized tests, and clean looking asserts.So need to convert most
setUp/tearDown
stuff to fixtures (a lot). properly use fixture scope (e.g. db stuff which you only want to create a database once per test run; this is the most complicated).Parameterized tests are awesome, but again, need to restructure tests a bit for that.
I suppose the actual assert mechanism could be changed, but a lot of care would be needed.
And here's the rub, I think we would have to simply switch, then start changing things as its not back-compat to nose.
Given all this I am not optomistic this could be done quickly/easily. The upside is nice & clean tests, but getting there is hard.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what's in the way of making the change to py.test and then in time move over to using its features? There's no need to move everything over immediately?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nothing really. If you want to investigate actually seeing what would be needed to be changed to simply run it (and might involved a py.test compat plugin), then would be willing to switch I think. Though of course would be nice to see what is involved in adding these things: fixtures, assertion nomenclature, parameterization (e.g. maybe do one test file to see what its like).
This was discussed a little bit on the mailing list, but I don't think an issue exists for it.