-
Notifications
You must be signed in to change notification settings - Fork 148
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
Introduce assert_component_equal
for tests
#195
Conversation
…ts-equal # Conflicts: # vizro-core/tests/unit/vizro/models/_navigation/test_nav_bar.py # vizro-core/tests/unit/vizro/models/_navigation/test_nav_link.py
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
Signed-off-by: Antony Milne <[email protected]>
assert_component_equal
for tests
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.
Thanks for this super helpful PR description! 🚀 Everything is clear 👍
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.
Lgtm! Have one suggestion, but it's a really cool feature, and really saves a lot of confusion and headache :)
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 really like the "assert_component_equal".
P.S. Thanks for the awesome description! 🚀
Description
I made a new testing utility function
assert_component_equal
as part of rewriting of tests in #70 but didn't advertise it widely before. I've just tweaked how it works so I'm happy with it now. I'll do a learning session on this on Weds 20th December to explain all.Just in terms of reviewing, there's not really anything to check here because most of the commits are just tidying up my implementation of
assert_component_equal
.The things that are of interest are:
assert_component_equal
Basic usage
When we compare the output of a
build
method to a Dash component tree, previously we were doing something like this:Now we do:
For example:
So it's just a nicer way of writing the same check. Think of it a bit like
pandas.testing.assert_frame_equal
.Advanced usage:
keys_to_strip
assert_component_equal
also has akeys_to_strip
argument that sets properties that will be ignored in the component comparison. Sometimes it's useful to setkey_to_strip={"id"}
since ourid
s are randomly generated (they're model manager ids) and we don't care about actually comparing them.The other use for this is in testing "high-level containers" vs. "low-level contents". This is used a lot in the navigation tests and demonstrated with a toy example in https://github.com/mckinsey/vizro/blob/tests/assert-components-equal/vizro-core/tests/tests_utils/demo_asserts.py.
In general any test where we have
keys_to_strip={"children"}
would be followed by a test onresult.children
usingSTRIP_ALL
.The idea is:
test_X_build
tests stuff that's only inX
test_Y_build
tests stuff that's only inY
test_Y_build
also tests thatY.build()
is correctly callingX.build()
but not the details of whatX.build()
returnsThe typical way you'd do case 3 is by providing a mock
X
and then doing something likeassert X.call_count == 4
. The current solution is arguably slightly "wrong" in that some of the implementation ofX.build
is leaking into thetest_Y_build
, because we are checking againsthtml.Div
. This is fine by me though, because it means we test the interface a bit more strictly, and it's much clearer, easier and less error-prone than writing mocks.Next steps
json.loads(json.dump(...))
intoassert_component_equal
. Most of these will just be simple find and replace as per the basic usagePage.build
using the "advanced usage"Checklist
Types of changes
Notice
I acknowledge and agree that, by checking this box and clicking "Submit Pull Request":