-
-
Notifications
You must be signed in to change notification settings - Fork 194
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
Test the location portal with a python test and a mocked GeoClue2 #1451
Test the location portal with a python test and a mocked GeoClue2 #1451
Conversation
ae0a259
to
be70f55
Compare
@whot CI fails with edit: Nvm, you added this "recently"... |
@GeorgesStavracas is it okay to add a more recent python-dbusmock for the tests? |
I'm not sure, it probably is fine. @whot knows better about the Python testing infrastructure and might have a more informed answer though. |
If we get the CI MR (#1334) in then we'd be using ubuntu:latest which ships with a recent python-dbusmock. |
be70f55
to
9ca21d4
Compare
CI is green now. |
It makes it possible to name those testcases without having to quote the names and helps with autocomplete.
They have been around for quite some time now but it's easy to accidentally not run them because they get disabled when the dependencies are not all satisfied. This enables pytests by default which forces one to explicitly disable them if they are unwanted.
but a DBusTestCase instead. It can be used to get access to a session and system bus but isn't a bus itself.
Same reason as previous commit.
Currently we only start a session bus but the portal frontend does try to communicate with some services on the system bus which might or might not work, depending on the system. This starts a fresh system bus to avoid messing with the running system and also makes sure no one accidentally depends on something that's specific to their local system. In the next commits we will start mocking one of those system services.
Not specifying the interface means that it will get emitted on different interfaces depending on how the template was loaded. Just specify the right interface and avoid all the trouble.
@whot could you take another look please? I have more python test changes in the pipeline. |
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 now, thanks
Instead of loading a single portal backend implementation, make it possible to load any number of templates. Each dbus name has one spawned dbus mock server and will potentially load any numbers of templates into it. This simplifies test cases which require multiple backends to be loaded such as the clipboard ones (clipboard + remotedesktop). It also will simplify tests which require external services to be mocked which are not portal implementations such as the location portal which requires GeoClue2.
The required_templates fixtures specifies to templates which are required to be mocked by the test case. By default this is the portal implementation of the portal that's being tested. The return value is a map where the values are the parameters which will be passed to the template. The template_params fixture allows to override the parameters of templates. This is especially useful when combined with the @pytest.mark.parametrize annotation. The clipboard tests are adjusted to make use of this.
This tests more than the C variant of the test and does not depend on the system provided GeoClue2 to function but instead uses a mocked GeoClue2.
9ca21d4
to
c2b83f2
Compare
c2b83f2
to
c23df7e
Compare
The python one uses a mocked GeoClue2 which is always available and the tests cases already check more than the C variant. Let's drop the C one which fails for weird reasons on some systems.
c23df7e
to
3b8edc8
Compare
No description provided.