This is the one biggish change between the last working test run in GitHub,
and now. Tests are still running locally fine, an on GitHub, in the last
run, I had one job pass and another fail, both on the same OS, just 3.10
passed and 3.9 failed. The problem still to do with (as far as I can tell)
messages inside Textual and some sort of async issue.
So let's try this.
Wondering if this is the issue with why the tests have stopped working in
GitHub; but also not *really* confused as to why they were working in the
first place.
This code is running just finally locally in tests, but is failing with:
RuntimeError: Task <Task pending name='Task-279' coro=<MessagePump._process_messages() running at /home/runner/work/textual/textual/src/textual/message_pump.py:314>> got Future <Future pending> attached to a different loop
in GitHub Actions. Pretty sure I saw this before, which made me add the
pause in the first place. Given this seems to just be affecting the last
test, from what I can tell, let's make the pause longer to see if that
helps.
I hate chasing action issues...
This is set to xfail at the moment because the tested result is what I think
should be the result, but what happens now isn't that. Need to check with
Will to see what he thinks the correct resolution is here.
I feel some more will be needed, but this is all of the basics, hitting all
of the important points that relate to #1343. More importantly all of the
xfails are now removed.
At the moment at least, we don't allow binding on " ", we bind on "space".
Meanwhile, tidy folk may try and bind in "a, b, c, d" as opposed to trying
to bind on "a,b,c,d". I feel we should allow for that.
This test, which breaks at the moment, should be satisfied.
While what I had worked, asserting on a boolean return from that method
ended up masking what had gone wrong. This way we get to see the fail
and *why* it failed.
The tests are getting a little involved, and aim to tell an important story
about how the binding inheritance works, currently causes problems, and
should eventually work. As such I feel it's time to tidy things up a bit,
reduce some of the copy/paste going on, and comment heavily so I don't lose
my place and thinking, not to mention hopefully help someone else reading
make sense of the tests.
Just to make it a bit more clear what's going on and why. There's a fair bit
goes into each of these tests and this module is in danger of getting quite
messy. I may revisit the layout at some point just to make it all a lot more
readable.
Rather than test that it has zero bindings (although that is a legitimate
test too), test for the thing we're really concerned about here: that it
doesn't have movement keys. That's what this is all about.
Not that this made a change to its passing/failing state right at the moment
-- it's going to fail anyway -- but it kinda needs to be in its proper "this
should pass" state.
