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.
