Skip to content

Latest commit

 

History

History

tests

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
assert
assert
 
 
conformance
conformance
 
 
console
console
 
 
containerdisk
containerdisk
 
 
flags
flags
 
 
framework
framework
 
 
libnet
libnet
 
 
libvmi
libvmi
 
 
network
network
 
 
reporter
reporter
 
 
storage
storage
 
 
BUILD.bazel
BUILD.bazel
 
 
Dockerfile
Dockerfile
 
 
OWNERS
OWNERS
 
 
README.md
README.md
 
 
access_test.go
access_test.go
 
 
config.go
config.go
 
 
config_test.go
config_test.go
 
 
conformance-config.json
conformance-config.json
 
 
console_test.go
console_test.go
 
 
container_disk_test.go
container_disk_test.go
 
 
credentials_test.go
credentials_test.go
 
 
default-config.json
default-config.json
 
 
entrypoint.sh
entrypoint.sh
 
 
infra_test.go
infra_test.go
 
 
job.go
job.go
 
 
kubectl_test.go
kubectl_test.go
 
 
kubevirt_configmap_test.go
kubevirt_configmap_test.go
 
 
migration.go
migration.go
 
 
migration_test.go
migration_test.go
 
 
operator_test.go
operator_test.go
 
 
pausing_test.go
pausing_test.go
 
 
pod_servers.go
pod_servers.go
 
 
replicaset_test.go
replicaset_test.go
 
 
security_features_test.go
security_features_test.go
 
 
stability_test.go
stability_test.go
 
 
storage_test.go
storage_test.go
 
 
subresource_api_test.go
subresource_api_test.go
 
 
template_test.go
template_test.go
 
 
test.go
test.go
 
 
tests_suite_test.go
tests_suite_test.go
 
 
utils.go
utils.go
 
 
version_test.go
version_test.go
 
 
virt_control_plane_test.go
virt_control_plane_test.go
 
 
vm_test.go
vm_test.go
 
 
vm_watch_test.go
vm_watch_test.go
 
 
vmi_cloudinit_hook_sidecar_test.go
vmi_cloudinit_hook_sidecar_test.go
 
 
vmi_cloudinit_test.go
vmi_cloudinit_test.go
 
 
vmi_configuration_test.go
vmi_configuration_test.go
 
 
vmi_controller_test.go
vmi_controller_test.go
 
 
vmi_gpu_test.go
vmi_gpu_test.go
 
 
vmi_headless_test.go
vmi_headless_test.go
 
 
vmi_hook_sidecar_test.go
vmi_hook_sidecar_test.go
 
 
vmi_hostdev_test.go
vmi_hostdev_test.go
 
 
vmi_ignition_test.go
vmi_ignition_test.go
 
 
vmi_iothreads_test.go
vmi_iothreads_test.go
 
 
vmi_lifecycle_test.go
vmi_lifecycle_test.go
 
 
vmi_monitoring_test.go
vmi_monitoring_test.go
 
 
vmi_multiqueue_test.go
vmi_multiqueue_test.go
 
 
vmi_servers.go
vmi_servers.go
 
 
vmidefaults_test.go
vmidefaults_test.go
 
 
vmipreset_test.go
vmipreset_test.go
 
 
vnc_test.go
vnc_test.go
 
 
windows_test.go
windows_test.go
 
 

README.md

Integration tests

Writing e2e tests

We aim to run e2e tests in parallel by default. As such the following rules should be followed:

  • Use cirros and alpine VMs for testing wherever possible. If you have to use use another OS, discuss on the PR why it is needed.
  • Stay within the boundary of the testnamespaces which we prove. If you have to create resources outside of the test namespaces, discuss potential solutions on such a PR.
  • If you really have to run tests serial (destructive tests, infra-tests, ...), mark the test with a [Serial] tag.
  • If tests are not using the default cleanup code, additional custom preparations may be necessary.

The following types of tests need to be marked as [Serial] right now:

  • Tests which use PVCs or DataVolumes (parallelizing these is on the way).
  • Tests which use BeforeAll.

Additional suggestions:

  • The [Disruptive] tag is recognized by the test suite but is not yet mandatory. Feel free to set it on destructive tests.
  • Conformance tests need to be marked with a [Conformance] tag.

Test Namespaces

If tests are executed in parallel, every test gets its unique set of namespaces to test in. If you write a test and reference the namespaces test.NamespaceTestDefault, test.NamespaceTestAlternative or tests.NamespaceTestOperator, you get different values, based on the ginkgo execution node.

For as long as test resources are created by referencing these namespaces, there is no test conflict to expect.

Running integration tests

Integration tests require a running Kubevirt cluster. Once you have a running Kubevirt cluster, you can use the -master and the -kubeconfig flags to point the tests to the cluster.

Run them on an arbitrary KubeVirt installation

cd tests # from the git repo root folder
go test -kubeconfig=path/to/my/config -config=default-config.json

Run them on one of the core KubeVirt providers

There is a make target to run this with the config taken from hack/config.sh:

# from the git repo root folder
make functest

Run them anywhere inside of container

# Create directory for data / results / kubectl binary
mkdir -p /tmp/kubevirt-tests-data
# Make sure that eveybody can write there
setfacl -m d:o:rwx /tmp/kubevirt-tests-data
setfacl -m o:rwx /tmp/kubevirt-tests-data

docker run \
    -v /tmp/kubevirt-tests-data:/home/kubevirt-tests/data:rw,z --rm \
    kubevirt/tests:latest \
        --kubeconfig=data/openshift-master.kubeconfig \
        --container-tag=latest \
        --container-prefix=quay.io/kubevirt \
        --test.timeout 180m \
        --junit-output=data/results/junit.xml \
        --deploy-testing-infra \
        --path-to-testing-infra-manifests=data/manifests