ZDTM API - Revision history

Xemul: /* Test's .desc file */

2016-09-01T13:32:11Z

Test's .desc file

2016-09-01T13:31:20Z

Test's .desc file

2016-09-01T13:29:02Z

2016-02-29T16:41:12Z

2015-02-26T16:19:30Z

2015-01-23T16:30:39Z

2015-01-23T16:25:43Z

2015-01-23T16:24:02Z

2015-01-23T16:18:15Z

2015-01-23T16:17:28Z

@@ Line 140: / Line 140: @@
 ; 'feature'
 : The feature that should be [[Checking the kernel|checked]] before running the test.
 == See also ==

@@ Line 133: / Line 133: @@
 ; 'flags'
-: Space-separated values. <code>suid</code>: test needs root prio to run. <code>noauto</code>: test is excluded from <code>--all</code> run of zdtm.py. <code>crfail</code>: dump should fail for this test. <code>nouser</code>: test cannot be checkpointed in [[user mode]]. <code>excl</code>: test should not be run in parallel with any other test. <code>samens</code>: no <code>--join-ns</code> testing.
+: Space-separated values. <code>suid</code>: test needs root prio to run. <code>noauto</code>: test is excluded from <code>--all</code> run of zdtm.py. <code>crfail</code>: dump should fail for this test. <code>nouser</code>: test cannot be checkpointed in [[user-mode]]. <code>excl</code>: test should not be run in parallel with any other test. <code>samens</code>: no <code>--join-ns</code> testing.
 [[Category: Development]]
 [[Category: Testing]]

@@ Line 125: / Line 125: @@
 All logs from test, including the pass/fail status would be in the <code>$test.out</code> file.
-== Adding test to automatic suite ==
+== Test's .desc file ==
-The above part of the article describes what should be done to make the test work itself. Now, to check how the test is dumped and restored one should add the test to the suite. This is done simply by editing the <code>test/zdtm.sh</code> script and adding the test name to the <code>TEST_LIST</code> variable. Some tricks apply though.
+Put the <code>${test_name}.desc</code> next to the test's .c file to configure the test. The .desc file can have the following fields in JSON format:
-=== Caring about namespaces ===
+; 'flavor'
-If your test behaves very differently when run inside sub-namespace or tests namespaces stuff, then the test should not be added to the very first definition of the <code>TEST_LIST</code> list, but instead to the one that goes after the <code># These ones are not in ns</code> comment, optionally with the <code>ns/</code> prefix.
+; 'flags'
 [[Category: Development]]
 [[Category: Testing]]

@@ Line 3: / Line 3: @@
 == Overview ==
-The ZDTM test-suite is the automated suite that launches individual subtests as processes, waits for them to get prepared, then dumps the process(es) started, then restores them and asks to check whether the restored state is what test thinks to be proper. In order to write more subtests developer should use the API declared below. Tests themselves live in one of <code>test/zdtm/live/</code> sub-directory. The full-cycle suite is the <code>test/zdtm.sh</code> script.
+The ZDTM test-suite is the automated suite that launches individual subtests as processes, waits for them to get prepared, then dumps the process(es) started, then restores them and asks to check whether the restored state is what test thinks to be proper. In order to write more subtests developer should use the API declared below. Tests themselves live in one of <code>test/zdtm/</code> sub-directory. The full-cycle suite is the <code>test/zdtm.py</code> script.
 == API for test itself ==

← Older revision		Revision as of 16:30, 23 January 2015
Line 126:		Line 126:

	== Adding test to automatic suite ==		== Adding test to automatic suite ==
		+
		+	The above part of the article describes what should be done to make the test work itself. Now, to check how the test is dumped and restored one should add the test to the suite. This is done simply by editing the <code>test/zdtm.sh</code> script and adding the test name to the <code>TEST_LIST</code> variable. Some tricks apply though.
		+
		+	=== Caring about namespaces ===
		+
		+	If your test behaves very differently when run inside sub-namespace or tests namespaces stuff, then the test should not be added to the very first definition of the <code>TEST_LIST</code> list, but instead to the one that goes after the <code># These ones are not in ns</code> comment, optionally with the <code>ns/</code> prefix.
		+
		+	=== Requiring special features ===
		+
		+	If in order to C/R the test some special support from the kernel is required, then CRIU itself should be taught to check this support with the <code>check --feature=$name</code> option (see cr-check.c file for details). The test itself should be conditionally added to the <code>TEST_LIST</code> variable. Check how the <code>static/tun</code> test is added for reference.

	[[Category: Development]]		[[Category: Development]]

@@ Line 84: / Line 84: @@
 </pre>
-The ''name'' is some name for the option. The variable of the same name should be declared and the ''--$name'' CLI argument would be passed upon test start.
+The ''name'' is some name for the option. The variable of the same name should be declared and the ''--$name'' CLI argument would be passed upon test start (this option would be parsed by <code>test_init()</code> call, so nothing more should be done to have the option available).
 The ''type'' is data type. Currently supported types are ''string'', ''bool'', ''int'', ''uint'', ''long'' and ''ulong''.