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.
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.
This is the heart of the issue introduced by
b48a1402b8
and which is being investigated in
https://github.com/Textualize/textual/issues/1343 -- the child widget can be
focused, but (as far as the author of the code is concerned) it has no
bindings. Bindings for movement-oriented keys exist on the screen which
composes up the widget into it. Up until 0.5.0 this worked just fine. As of
0.6.0, because binding inheritance was introduced, the bindings for movement
that live at the `Widget` level cause the widget that has no bindings to
appear to have bindings.
While this can potentially be worked around with the use of
inherit_bindings, this isn't a very satisfying solution and also breaks the
rule of least astonishment.
This test is going to be key to all of this. This is the test that should be
made to work without breaking any of the other currently-passing tests.
Rather than just test a single specific movement key (in this case "up"), go
with all the affected keys. The cost to doing so is zero and it means we get
a full coverage of testing for all the keys that have become a problem with
0.6.0.
Up until now there doesn't seem to have been any unit tests aimed squarely
at setting up bindings, as part of a running application, which are only
about testing the bindings. As such there was no way of slotting in tests
for how inheritance of bindings works.
This starts that process with a view to testing how inheriting
likely *should* work.
See #1343 for some background to this.
