Writing tests for a pyglet application

105 views
Skip to first unread message

Paul Everitt

unread,
May 17, 2018, 10:21:50 AM5/17/18
to pyglet-users
I'm a contributor to Arcade, the Python 3.6+ 2d game library. I'm converting the existing doctests to pytest and trying to introduce some faster unit testing. In particular, not firing up a GUI window on each test.

I had hoped to make a MockWindow that I used to stub pyglet.window.BaseWindow. The challenge: this line:

from pyglet.window import Window

...immediately triggers a GUI window. Here are the last three lines in pyglet.window.__init__.py:

# XXX remove
# Create shadow window. (trickery is for circular import)
if not _is_pyglet_docgen:
pyglet.window = sys.modules[__name__]
gl._create_shadow_window()

The last line is done with non-import trickery that appears beyond the reach of mocking. Thus, I'm interested in some feedback:

- Am I totally on the wrong path, and unit testing a method on a subclass of BaseWindow requires a window?

- Should I refactor arcade.Window to subclass from something which subclasses BaseWindow, to give me a place to step in?

- Does anybody have a pyglet application with tests that don't spawn windows?

Thanks, and I confess that it is likely I am looking at this all wrong.

--Paul

Chris Norman

unread,
May 17, 2018, 10:29:28 AM5/17/18
to pyglet-users
Hi,
I have never written tests for Pyglet, so please take whatever I say with a pinch of sault. I do however know that there is an option for not having the shadow window. I think it's pyglet.options['SHADOW_WINDOW'] = False.

HTH,

--
You received this message because you are subscribed to the Google Groups "pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users+unsubscribe@googlegroups.com.
To post to this group, send email to pyglet...@googlegroups.com.
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.



--

Take care,

Chris Norman

Paul Craven

unread,
May 17, 2018, 11:01:49 AM5/17/18
to pyglet-users
What does the shadow window do? There's not much documentation there, aside from "XXX Remove"


On Thursday, May 17, 2018 at 9:29:28 AM UTC-5, Chris Norman wrote:
Hi,
I have never written tests for Pyglet, so please take whatever I say with a pinch of sault. I do however know that there is an option for not having the shadow window. I think it's pyglet.options['SHADOW_WINDOW'] = False.

HTH,
On Thu, May 17, 2018 at 3:21 PM, Paul Everitt <paulwe...@gmail.com> wrote:
I'm a contributor to Arcade, the Python 3.6+ 2d game library. I'm converting the existing doctests to pytest and trying to introduce some faster unit testing. In particular, not firing up a GUI window on each test.

I had hoped to make a MockWindow that I used to stub pyglet.window.BaseWindow. The challenge: this line:

from pyglet.window import Window

...immediately triggers a GUI window. Here are the last three lines in pyglet.window.__init__.py:

# XXX remove
# Create shadow window. (trickery is for circular import)
if not _is_pyglet_docgen:
pyglet.window = sys.modules[__name__]
gl._create_shadow_window()

The last line is done with non-import trickery that appears beyond the reach of mocking. Thus, I'm interested in some feedback:

- Am I totally on the wrong path, and unit testing a method on a subclass of BaseWindow requires a window?

- Should I refactor arcade.Window to subclass from something which subclasses BaseWindow, to give me a place to step in?

- Does anybody have a pyglet application with tests that don't spawn windows?

Thanks, and I confess that it is likely I am looking at this all wrong.

--Paul

--
You received this message because you are subscribed to the Google Groups "pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users...@googlegroups.com.

To post to this group, send email to pyglet...@googlegroups.com.
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.

Chris Norman

unread,
May 17, 2018, 11:06:08 AM5/17/18
to pyglet-users
I have literally no idea mate. Alls I know is that if you turn it off you remove some random crashes that can occur wiht screen reading technologies.

HTH

To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users+unsubscribe@googlegroups.com.

To post to this group, send email to pyglet...@googlegroups.com.
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.

Paul Everitt

unread,
May 17, 2018, 8:33:47 PM5/17/18
to pyglet-users
FWIW, I've had some progress (after having a number of hilarious potholes). 

@pytest.fixture(autouse=True)
def mock_window(monkeypatch):
sys.is_pyglet_docgen = True
monkeypatch.setattr('pyglet.window.Window', MockWindow)
from arcade import Window
return Window

As long as I ask for this fixture in my tests and don't import anything that might import pyglet in the tests, it works and uses my own MockWindow in the place of pyglet.window.Window.

My tests are going pretty fast now.

Benjamin Moran

unread,
May 18, 2018, 9:51:48 AM5/18/18
to pyglet-users
Hi guys,

The shadow window stuff was written before my time, but it's basically an OpenGL context created on a hidden window. The purpose was/is to allow users to load resources (Textures) before creating a Window.  I'm not sure how useful it really is to keep. If removed, we could just raise a detailed exception telling users to "please create a Window before loading images" or something to that effect.  There may be some projects that depend on this functionality out there, so it's worth discussing before removal.

The documentation stuff is in need of a cleanup. Recently, certain IDEs were hitting bugs with the _is_epydoc checks in the codebase, due to setting these things themselves. I believe it's for online documentation, but I'm not positive. In any case, the current plan is to remove all of the documentation checks from the codebase. Modern documentation tools have made all of this obsolete, so we should be able to clean a lot of this cruft out of the library. Anyone who is wanting to help out with that would be most welcome!

-Ben
Reply all
Reply to author
Forward
0 new messages