-
Notifications
You must be signed in to change notification settings - Fork 6
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
[draft] test: integration test framework #20
base: main
Are you sure you want to change the base?
[draft] test: integration test framework #20
Conversation
b0ab323
to
03ab1e2
Compare
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.
Impressive work!
I haven't looked into the server parts (this we will totally move from integration
repo based to mender-server
based). The rest I read enough to get an idea of the design and I dropped some comments where I saw fit.
The next step I think is for us to sit together and break it down into small tasks for the upcoming springs 📝
} | ||
|
||
int | ||
main(void) { |
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.
The main()
is the same as for the reference application, right? Then I think we should refactor it so that we have one file for the main() that is shared and one separate file for the callbacks that can be different.
This is to avoid pitfalls of modifying the code in only one of the tests.
Alternatively, we could mark the callback as weak function attributes in the reference app, and for the integration tests only override these. I like this second approach more, as it can also be easier extended by users if they want to reuse our reference app for quick 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.
The
main()
is the same as for the reference application, right?
Except for the test_update_module_register()
, of course. Then, I don't know what could be a good design to share this code 🤔
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.
Yes, it's the same but with the callbacks defined and test_update_module_register()
, as you said. I guess we could guard the test update module with #ifdef CONFIG_INTEGRATION_TEST
in the reference application main
"-DCONFIG_LOG_MODE_IMMEDIATE=y", | ||
"-DCONFIG_MENDER_LOG_LEVEL_OFF=n", | ||
"-DCONFIG_MENDER_LOG_LEVEL_DBG=y", | ||
f'-DINTEGRATION_TESTS="y"', |
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.
This one should also be CONFIG_...
"-DCONFIG_MENDER_LOG_LEVEL_DBG=y", | ||
f'-DINTEGRATION_TESTS="y"', | ||
f'-DCONFIG_MENDER_SERVER_HOST="{self.server_host}"', | ||
f'-DCONFIG_MENDER_SERVER_TENANT_TOKEN="{self.server_tenant}"', |
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.
Just FYI, the CONFIG_
prefix is for defines injected by KConfig. We are free to chose any prefix that we like. Maybe we should use a different one for easily distinguish what is coming from KConfig and what from the test framework?
target_sources(app PRIVATE | ||
src/main.c | ||
src/utils/netup.c | ||
src/utils/certs.c | ||
) | ||
endif() | ||
|
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.
This we will need to rework after my refactor in mendersoftware/mender-mcu#97 🙈
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.
Looks good to me otherwise.
# Defaults to `https://docker.mender.io` | ||
self.set_host() | ||
|
||
def set_host(self, host="https://docker.mender.io"): |
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.
What is docker.mender.io
?
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.
The URL of the demo server
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.
Would be nice to add a comment on what it is and how to get (access to) it.
|
||
def stdout(device): | ||
line = device.proc.stdout.readline() | ||
if device.stdout: |
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.
Maybe has_stdout
would be a better name?
URL_DEPLOYMENTS_STATUS = "/deployments/{id}/status" | ||
|
||
|
||
class Server: |
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.
Isn't there a class like this in the mender_integration
repo?
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.
Not with as explicit methods as abort_deployment
etc., and not where you could easily connect to hosted.mender.io, at least as far as I could tell. But this server part was really only done this way to get something working. It will need to be reworked anyways, because the server-part is being moved from integration to mender-server (as Lluis said), plus the demo-server doesn't work
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.
Cool, thanks for the extra explanation.
03ab1e2
to
3038797
Compare
Integration test framework for testing mender-mcu client with native-sim. Still requires work - e.g. making the demo server work, and probably more work on the testing framework itself. It uses `integration` as a submodulel, so you need to init it. You have to set tenant token, auth_token etc. manually, and I've only tested it with 'hosted.mender.io'. I went with the compile-in approach: You can modify the callbacks directly in the test. You do this by utilizing `set_callback()` from `helpers`. The available callbacks you can modify are stored in `callbacks.py`. The callbacks have an #ifdef, and the python script creates a header-file which is imported by the test-update-module. The test-update-module and the main-file for the tests are located in the `src/` in the integration-tests directory. Ticket: MEN-7599 Signed-off-by: Daniel Skinstad Drabitzius <daniel.drabitzius@northern.tech>
3038797
to
5ac481c
Compare
And some small other adjustments, like * setting up the server as a fixture etc., * allow you to pass e.g. `hosted.mender.io` as a flag when running pytest We only use some functions from integration now, but that is related to logging Ticket: MEN-7675 Signed-off-by: Daniel Skinstad Drabitzius <daniel.drabitzius@northern.tech>
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.
Looks good to me other than those nitpicks.
|
||
def compile(self, pristine=False, extra_variables=None): | ||
if extra_variables is None: | ||
extra_variables = [] |
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.
You can do extra_variables = extra_variables or []
, but your version is more explicit.
command_output = " ".join(command) | ||
pytest.fail(f"Failed to compile with command: {command_output}") | ||
|
||
def start(self, compile=True, pristine=False, extra_variables=[]): |
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.
Another empty list as a default argument.
|
||
from mender_integration.tests.MenderAPI import logger | ||
|
||
THIS_DIR = os.path.dirname(os.path.abspath(__file__)) |
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.
You can drop os.
here.
Signed-off-by: Daniel Skinstad Drabitzius <daniel.drabitzius@northern.tech>
This does not run in any pipeline, nor does it use any docker-images as of now
To run the sample test, navigate to the integration directory and run e.g.
pytest -s
. You must set the following variables in manually inside the test:tentant_token
auth_token
device_id
The test is configured to run using hosted.mender.io, as I couldn't get the demo servers to work (possibly due to the self-signed certificate)
Note that this test also uses the
native_sim
board, so it will also require you to setup the network - and the current README doesn't entirely cover it.