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
Added unit test for surface.get_colorkey(). Closes #1801 #1881
Conversation
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.
Looks good! The only other thing to check is the two asserts the function raises in this bit of C code here:
if (!surf)
return RAISE(pgExc_SDLError, "display Surface quit");
#if IS_SDLv1
if (surf->flags & SDL_OPENGL)
return RAISE(pgExc_SDLError, "Cannot call on OPENGL Surfaces");
Which I think should bubble up to the python code when you try to use get_colorkey() on the display surface (returned from set_mode()), after display.quit() has been called, and for the second one when you try to use get_colorkey() on the display surface created with the pygame.OPENGL flag - but only under SDL1. Both of these should hopefully be testable with self.assertRaises().
The last one will only be easily testable on your computer if you install pygame 1.9.6, but there should be a few examples in the other tests of how to flag a chunk of code to only run under SDL 1 and the Continuous Integration tests should also test it now on Travis.
Thanks for contributing!
(The CI failing is not your test it's another one we recently added to test the time module)
… is called after pygame.display.quit()
Okay, I just added the two new unit tests. |
… the first case I should add
I seem to be failing the integration tests because they don't raise pygame.error within the two new cases, even though on my machine, it raises the error. |
Hmm, it may be that the 'dummy' video driver, which is used on CI, doesn't invalidate surfaces in the same way? I'm not certain. I suppose you could test it locally by adding
Somewhere at the top of the test file temporarily and see if it breaks the assert firing locally. If so, perhaps the best thing to do is pull out that test and put it into a separate test_function (something like 'test_get_colorkey__quit_assertion' and then use the skip decorator if the video driver is == to dummy . e.g. Lines 555 to 559 in ccfe35c
|
Should probably also note that color keys are an area with lots of bugs hovering around them right now so it may be that there are genuine code problems. |
Maybe the fix in merged in with the PR #1899 will change this now. There was a problem when quit()/init() were called. Edit: yeah, this fixes it. To test it, I merged master branch into this PR, and the tests worked: #1907 So merge in master, or rebase against master and the CI robots should be happy. |
@illume I think we could probably just restart the Appveyor CI on our end couldn't we? At least that worked to fix Travis. I just don't have the power to restart Appveyor. |
Oh yeah. We can just merge this in now... because tests pass. No need to do it in this pr. |
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.
👍 thanks!
Some of the original code was actually wrong. For instance, checking the type of the returned value from surface.get_colorkey() to see if it is a Color object or an instance of a child class of Color.
I also added some more cases to make the test more comprehensive. For example, checking what happens when you set the color key using an RGBA value, the alpha not 255, and what surface.get_colorkey() should return.