Add unit test: mouse.get_cursor() (1762)

[GalacticEmperor1]

Issue №1762 opened by MyreMylar at 2020-05-16 18:33:58

This function needs a unit test.

Guide to how to contribute to an open source project on GitHub.

Test stub: https://github.com/pygame/pygame/blob/master/test/mouse_test.py# L16-L18
Docs: https://www.pygame.org/docs/ref/mouse.html# pygame.mouse.get_cursor
Code to be tested: https://github.com/pygame/pygame/blob/master/src_c/mouse.c# L281-L323

---

Comments

# # Reminisque commented at 2020-06-08 06:11:36

Hello. I would like to contribute. May I get assigned this issue?

---

# # MyreMylar commented at 2020-06-08 06:17:31

Absolutely! 👍

---

# # Reminisque commented at 2020-06-09 04:55:46

I forked and clone the repo, but I could not get the testing to run as the pygame module could not be found when importing. Am I supposed to install pygame through pip before working on it or am I supposed to follow the instructions here https://www.pygame.org/wiki/CompileWindows ?

Also are there any other dependencies I need to download or other instructions I need to follow?

---

# # MyreMylar commented at 2020-06-09 05:54:46

Ah windows.

In my experience it is easier to get the sdl1 build working now. So from the pygame directory try:

python setup.py clean --all
python -m buildconfig -sdl1
python setup.py install
pip install . -U

That's what I tend to do. I think this unit test should have the same behaviour on SDL 1 and SDL 2 so you can probably rely on the CI.

---

# # Reminisque commented at 2020-06-09 06:44:46

I tried the instructions, but I'm getting the following error:

distutils.errors.DistutilsPlatformError: Microsoft Visual C++ 14.2 is required. Get it with "Microsoft Visual C++ Build Tools": https://visualstudio.microsoft.com/downloads/

I downloaded and installed the build tools required and updated the setuptools package. However it's still giving me the error when I try to run the first command again.

---

# # MyreMylar commented at 2020-06-09 07:45:08

Ah yes, you may also need to setup environment variables, or perhaps run the developer command prompt to unstick it:

For example, here are my environment variable for the many versions of Python I have installed:

the MSVC compiler confusingly has lots of different version names. It looks like you need this one to build C extensions with your version of Python:

MSVC++ 14.2 _MSC_VER == 1920 (Visual Studio 2019 Version 16.0)

Possibly you can set the command line environment variables like this:

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/how-to-set-environment-variables-for-the-visual-studio-command-line

You likely need to restart whatever editor or command line program you are using before environment variable changes take effect.

---

# # MyreMylar commented at 2020-06-09 07:48:25

Building C extensions on windows with python can be pretty confusing, partly because Microsoft has changed the location of the MSVC compiler about five times (not that Python on Windows has been any better about picking a location and sticking to it) - partly because you need a different version of the compiler for different versions of Python, and partly because most developers in this area seem to use linux and look at you slightly confused when you mention programming on windows.

It's a lot basically :) It is possible though, I'm living proof!

---

# # Reminisque commented at 2020-06-10 02:35:02

I ran VsDevCmd as instructed in the link provided and it added VS142COMNTOOLS to system variables with this value:

C:\Program Files (x86)\Microsoft VIsual Studio\2019\BuildTools

I tried to see if this worked before adding \Common7\Tools to the end of it and it did not work.
After adding \Common7\Tool to the value, it still can't seem to find the build tools needed.

Is there a problem with the version of Python or the build tools that I have? Currently I have the 64-bit version of Python 3.8.3 and the build tools are version 16.2.2. I also have MSVC v142 and the latest Windows 10 SDK checked in the build tools installer.

---

# # Reminisque commented at 2020-06-10 10:58:42

Actually, it turns out the variable was what I set before and thought I had deleted when I had a hunch it might have been a environment variable issue. After running the bat file, it doesn't seem to have changed anything.

I tried switching to Python 3.8 32-bit as well as Python 3.7 64-bit, but the issue persists with both. I also followed the instructions from the following link in using the SET command in the developer prompt to see the environment variables:

https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=vs-2019

This is part of what I got:

I noticed that the correct variable was VS160COMNTOOLS, but changing it did not fix the issue.

I did a little investigating of the trackback and a google search led me to find that other people are experiencing the same issues recently:

pypa/setuptools#2028

---

# # MyreMylar commented at 2020-06-10 11:02:52

Hmm, things to try:

1. Make sure the python package setuptools is upgraded, I think everytime microsoft moves where the build tools are located they have to update setuptools in a never ending arms race.

pip install --upgrade setuptools

2. Make sure the build tools include the Visual C++ tools, apparently it's possible to get them without C++? I guess if you only want to use C# or something. You used to be able to modify the installation to change exactly what was in it.

I guess you could also try older versions of the build tools or older versions of python? I'm currently building on 3.8.2 - 32 bit.

---

# # Reminisque commented at 2020-06-12 03:24:21

I finally got it working I think. I had tried python 3.8 64- and 32-bit, 3.7 32-bit, and 3.6 32-bit. For the MSVC versions I tried 14.2 and 14.1, but only just now after I tried MSVC 14.0 (2015 version) with python 3.6 did the commands from before started going through. I switched back to python 3.8.3 64-bit and it still works. I also noticed that after installing 14.0, it changed VS140COMNTOOLS in my system variables to the correct path compared to 14.2 which did not change anything. I currently have both MSVC 14.2 and 14.0 installed, but I'm pretty sure that 14.0 is whats fixing the issue.

I followed the instructions from before and I think I was able to get pygame set up. I am able to run the tests in the test folder just fine.

In regards to SDL1 and SDL2, do I just need to test if it returns the TypeError raised for SDL2 and test the method normally for SDL1?

---

# # MyreMylar commented at 2020-06-12 07:34:45

Hooray!

In regards to SDL1 and SDL2, do I just need to test if it returns the TypeError raised for SDL2 and > test the method normally for SDL1?

Looking at the code that seems accurate. You can test the SDL version, (quite a few tests do it if you search the test folder for: SDL2) directly in the test or you can split it into two tests one for SDL 1 and one for SDL 2. I'd probably just branch the one test for something simple like this because it's only the assert to test on SDL 2. There is the with self.assertRaises(your assert here): pattern you can use and you should see plenty of examples of it in the code in the test folder.

For SDL 1, be aware of code hidden in C macros like VIDEO_INIT_CHECK which is almost certainly some code that checks if display is initialised and returns an assert if it is not. You can test this by doing something like:

pygame.display.init()
try:
    # normal testing of what function does
finally:
    pygame.display.quit()
    with assertRaises(whatever the assertion is here):
        pygame.mouse.get_cursor()

Other things to be aware of, the SDL documentation:

https://wiki.libsdl.org/SDL_GetCursor

says that the function will return NULL if there is no mouse, which may mean that the CI platforms (travis and appveyor) don't work because the code is running on some server machine somewhere with no monitor and no peripherals plugged in. Only way to know is to try, and then if it doesn't work you can use that to test the assert for what happens when no mouse is plugged in and only test the rest if there is a mouse.

---

# # Reminisque commented at 2020-06-14 01:27:51

For the VIDEO_INIT_CHECK macro, I was unable to follow the try-finally pattern you suggested. There is this class at the top of mouse_test.py that seems to be initializing the display before the tests and quitting the display afterwards.

class MouseTests(unittest.TestCase):

    @classmethod
    def setUpClass(cls):
        #  The display needs to be initialized for mouse functions.
        pygame.display.init()

    @classmethod
    def tearDownClass(cls):
        pygame.display.quit()

When I tried the pattern, pygame.display.quit() in the finally block causes the display to be uninitialized and fail the rest of the tests since the test for pygame.mouse.get_cursor comes first and the other tests don't handle the macro.

Should I just test it similarly to the other tests without the assert on VIDEO_INT_CHECK?

---

# # MightyJosip commented at 2020-06-27 13:43:10

This is now done thanks to the # 1955 by @Reminisque. Thanks 👍