-
Notifications
You must be signed in to change notification settings - Fork 91
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
Grids GUI test #231
Grids GUI test #231
Conversation
Looking good so far. Thanks for turning the crank on Travis; truly a thankless job :( |
Thanks! Here's the progress I've made so far:
So my current problem is getting the test to pass in the Travis environment. This is not easy to do, because there isn't a display that allows me to see what the test is doing to the UI. I have two approaches in mind, both of which I cannot do by myself:
I am currently experimenting with the screen recording approach, and testing locally. Will let you know how this goes! |
Sounds like you've made lots of progress. I think having tests that can run in any environment is enough of an improvement that it'd a shame to hold this up getting the tests to run under Travis. Maybe for now we can just disable the test under Travis, merge this PR and go from there? Looks like a good way to disable tests under travis is to set an environment variable in the travis config and look for it in a |
So I think path forward would be to revert most of the Travis changes, but probably retain them on another branch somewhere; I think we will want to circle back to this, and it looks like you learned a lot. Let's add an env var to disable problematic tests. We can close #133 and open a new issue for getting the tests to work under Travis. |
Sounds good to me! |
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.
It looks like there is still stuff left over from trying to figure out what Travis is up to (sorry, i know its really frustrating to try to figure out what CI systems are up to, especially when pytest
is so eager to hide all output from you 😡). So let me know when you think this is good to go and I'll do a full review.
For now, I want to get ahead of some content things earlier rather than later. Mainly, I've got to look into whether we are okay with the little LGPL snippet. I think for that to be there, we would need to have a license notice displayed somewhat prominently that there is LGPL code in ARMI. Not sure if we want to go that route (at least not to accommodate such a little snippet). Also, technically according to the CLA, anything that isn't original work needs to be submitted separately (i think so that we can consider it's copyright holder and license terms separately and make sure we incorporate everything properly). So! if at all possible, it would be nice if the _cleanup()
function could be adjusted/adapted enough that we can make a fair-use argument that it is original work. Think that's possible?
Yep, happy to adjust the _cleanup() function. I agree that it's best to avoid having LGPL code in the codebase. Will update once the PR is in a more ready state for a proper review! |
Ready for review, PTAL! Thanks! |
Oops, not quite ready yet! Will update again when ready. |
This is ready now! |
(Not sure why test coverage dropped.) |
Thanks for all this work. I'm not sure why Travis test results are so detached from this PR (failing unit tests should have come with a prominent check failure, so that's probably a new open issue) but checking into it, it looks like the unguarded Maybe shove the |
Now there appears to be an issue with "pip install black" :( Will update when I figure out why. Update: There was a transient issue with the black GitHub action, it should be fine now. |
It's ready now! |
Whew, nice. Though our test suite only runs up to Python 3.7, I ran this on my Python 3.8 Linux box and got a failure. Have you seen anything like this? Could indicate that there's some important change in an underlying lib that we don't have expressed in requirements.txt, etc.?
|
That's unfortunate -- looks like it only works on my machine, eh? This is what I see:
I'm wondering if it could be some difference between our display settings. Would you mind running the test again without disabling xvfb and pasting the output here? Like this:
|
The previous time I was running through a ssh with X forwarding so I thought that might be an issue and ran again locally with this command. Similarly, I get:
|
@scottyak I am going to try to get these tests working locally myself, and once successful, I think we should merge this. You've done a lot of great work on this, and we can always circle back to this long-tail stuff later. Having any tests at all is going to be a huge get, even if it's not running under CI. |
If you don't mind me asking, what sort of environment are you running under locally? Distro, python version, etc? If i get stuck, a |
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 was able to make this work on my end! I had to make sure that i was running under a pure X11 environment. On my system, the default Gnome DE runs under Wayland. If you think you have this running under Wayland, let me know! Since this might go over some folks' heads, I'm thinking that we may want to make the tests opt-in. I played around with a @pytest.mark.skipif
decorator, which seemed to do the trick. I also had to make the tick time a little longer for the assertion to reliably pass; i think it was asserting before the app had a chance to fully respond to the event.
So i think that skipif
and a longer tick, and this is good to merge. Thanks so much! I know fighting with Travis is a bit of a slog :(
|
This commit adds the `GuiTestCase` class, as well as an example UI test. At the start of each test, a new instance of the `GridBlueprintControl` class is created and displayed, and the test author can define the sequence of actions to be simulated using `wx.UIActionSimulator`, and check that the properties of the `GridBlueprintControl` instance are as expected. The test can also be run in headless mode with `pytest-xvfb`. Unfortunately, this test only works in certain environments (we've only gotten it to work locally on Linux with pure X11 environments), so we are disabling the tests for now.
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.
Alrighty, this looks good to go! Thanks for doing this :) Really good to have some coverage on this GUI stuff.
And thank you all for being so responsive to comments! |
This is just a skeleton to demonstrate how the UI test would work. More cleanups to follow if folks agree on the general approach.