Introduce an E2E testing framework #258
Conversation
mtjhrc
force-pushed
the
tests
branch
6 times, most recently
from
d97941d to
0a08462
Compare
mtjhrc
force-pushed
the
tests
branch
5 times, most recently
from
e20a964 to
1245f79
Compare
mtjhrc
force-pushed
the
tests
branch
2 times, most recently
from
13752cd to
fdd7bb8
Compare
Cargo.toml
Outdated
| @@ -1,5 +1,5 @@ | |||
| [workspace] | |||
| members = ["src/libkrun"] | |||
| members = ["krun-sys", "src/libkrun"] | |||
There was a problem hiding this comment.
krun-sys is published in crates.io and packaged in Fedora. Can we consume it from there?
There was a problem hiding this comment.
Oh, I didn't know that. But where is the repository for that? Is it the one in muvm? I think we should consume it locally and publish the version located here in crates.io.
Wouldn't the crates.io version depend on system wide installation of libkrun? (something we want to avoid here).
There was a problem hiding this comment.
Oh, I didn't know that. But where is the repository for that? Is it the one in
muvm? I think we should consume it locally and publish the version located here incrates.io
Yes, it's that one. Perhaps it should be moved here, perhaps it should have its own repo in github.com/containers, perhaps it can stay in muvm but we should definitely consume it from crates.io.
Wouldn't the crates.io version depend on system wide installation of libkrun? (something we want to avoid here).
In its current state, yes. I'm going to create a PR to use pkg-config to find out the location of libkrun. That should allow us to use the local installation from test-prefix.
There was a problem hiding this comment.
What would be the advantage of using it from crates.io if it was in this repository here? In that case I think it makes more sense for the tests to use the potentially unpublished and potentially broken newest version of krun-sys (though admittedly since everything is auto-generated it is not that important).
|
This is looking good, nice work here. There a couple of very small things to fix, and consume |
|
I've just published a new version of krun-sys, 1.10.1, which combined with #270 should help us avoid vendoring the crate. |
mtjhrc
force-pushed
the
tests
branch
2 times, most recently
from
04befe9 to
cceb4eb
Compare
|
I've changed it to use the new version of krun-sys, all the env variables should now use realpath. |
Add a tests directory containing an E2E testing framework.
The tests are E2E in the sense that they use the public API of libkrun to
start a VM and run a test program in the guest.
Note that currently this is very limited, because there are no other userspace
executables or libraries (not even libc) in the guest apart from `guest-agent`.
`guest-agent` is a statically linked Rust executable, that executes the guest
part of each test.
In the future this can be extended to run tests with specific images which would
allow the use of system libraries by the test program.
This also introduces 2 tests:
test_vm_config - asserts the VM is constructed with the correct number of CPUs
and amount of memory. This also serves as an example how the
tests can be parameterized.
test_vsock_guest_connect - This tests the guest connecting to a vsock port
created by the `krun_add_vsock_port` API.
Signed-off-by: Matej Hrica <mhrica@redhat.com>
The install target should depend on generation of the libkrun.pc file, because it installs it. The libkrun.pc target should be .PHONY because libkrun.pc file might already exists and be generated, but it could be made using a different PREFIX, which would lead to the installed libkrun.pc pointing to the wrong prefix. Signed-off-by: Matej Hrica <mhrica@redhat.com>
Intruduce a test target in Makefile, that runs the e2e tests agains the built binary. Signed-off-by: Matej Hrica <mhrica@redhat.com>
This PR adds a testing framework for writing (mostly) end-to-end tests using libkrun.
The tests are E2E in the sense that they use the public API of libkrun to start a VM and run a test program in the guest. Note that currently this is very limited, because there are no other userspace executables or libraries (not even libc) in the guest apart from
guest-agent.guest-agentis a statically linked Rust executable, that executes the guest part of each test.In the future this can be extended to run tests with specific images which would allow the use of system libraries by the test program.
This also introduces 2 tests:
test-vm-config- asserts the VM is constructed with the correct number of CPUs and amount of memory. This also serves as an example how tests can be parameterized.vsock-guest-connect- This tests the guest connecting to a vsock port created by thekrun_add_vsock_portAPI.You can run these tests using
make test.Note: Currently these tests won't be ran on CI, because we need a CI that supports nested virtualization.