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.
For now anyway. I suspect this definition if is_scrollable will become moot
soon (ideally there would never be an is_scrollable property at all, ever,
as inheritance should ideally dictate this if the changes that are planned
go the way as planned -- a property that tells you something about
provenance when the inheritance tree tells you that is some bad OO smell)
but I want to get the tests set up as their own PR first and *then* work on
the fix.
By making use of __dict__ we have a simpler way of determining if the class defines its own default_css which does not involve comparing with the base class's default_css.
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.
The code is exactly the same between is_container and is_scrollable, and the
intent (confirmed in
https://github.com/Textualize/textual/issues/1343#issuecomment-1347989752)
is that the latter is intended to be overridden in some circumstances (so
far only in `ScrollView`). As such I feel it better conveys intent and
reduces the changes of mismatched future changes if is_scrollable is defined
in respect to is_container.
The only possible reason I can think of is if there's a measurable
performance win here. Applying Knuth for the moment, at least for the scope
of this PR. I strongly suspect this is one of the 97% rather than one of the
3% and for the purposes of moving stuff around (which I may be doing as I
explore this) I believe this makes it easier to follow and to think about.
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.
