Document basic parallel-test execution needs

Signed-off-by: Roman Mohr <[email protected]>

tests/README.md

@@ -1,5 +1,43 @@
 # 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 Fedora or a lot of memory for other reasons.
+ * 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.