From 914b3e061b0288e80a33d16961abd1810124e4eb Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Wed, 19 Mar 2014 07:27:09 -0600 Subject: dev-manual: Read-thru edits for "Performing Automated Runtime Testing" Minor edits. (From yocto-docs rev: 29b999f259bc9c87ad0b2e3c1d54f5473b66edbc) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- .../dev-manual/dev-manual-common-tasks.xml | 36 +++++++++++----------- 1 file changed, 18 insertions(+), 18 deletions(-) (limited to 'documentation/dev-manual') diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml index 5223aba158..b2dfc52a2d 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/documentation/dev-manual/dev-manual-common-tasks.xml @@ -5575,8 +5575,7 @@ These tests are written in Python making use of the unittest module, and the majority of them - run commands on the target system over - ssh. + run commands on the target system over SSH. This section describes how you set up the environment to use these tests, run available tests, and write and add your own tests. @@ -5623,7 +5622,7 @@ Be sure your host's firewall accepts incoming connections from 192.168.7.0/24: - Some of the tests (in particular smart tests) start a + Some of the tests (in particular smart tests) start an HTTP server on a random high number port, which is used to serve files to the target. The smart module serves @@ -5649,7 +5648,7 @@ You can start the tests automatically or manually: - Automatically Running Tests: + Automatically running tests: To run the tests automatically after the OpenEmbedded build system successfully creates an image, first set the @@ -5660,16 +5659,17 @@ TEST_IMAGE = "1" - Next, simply build your image. + Next, build your image. If the image successfully builds, the tests will be run: bitbake core-image-sato - Manually Running Tests: - To manually run the tests, first globally inherit - testimage.class - by editing your local.conf file: + Manually running tests: + To manually run the tests, first globally inherit the + testimage + class by editing your local.conf + file: INHERIT += "testimage" @@ -5704,7 +5704,7 @@ Each test module loads in the order found in TEST_SUITES. You can find the full output of the commands run over - ssh in + SSH in ${WORKDIR}/testimgage/ssh_target_log. If no failures occur, the task running the @@ -5723,7 +5723,7 @@ A test name maps directly to a Python module. Each test module may contain a number of individual tests. Tests are usually grouped together by the area - tested (e.g tests for systemd reside in + tested (e.g tests for Systemd reside in meta/lib/oeqa/runtime/systemd.py). @@ -5749,7 +5749,7 @@ required test for the image. Test modules named within TEST_SUITES cannot be skipped even if a test is not suitable for an image - (e.g. running the rpm tests on an image without + (e.g. running the RPM tests on an image without rpm). Appending "auto" to TEST_SUITES causes the build system to try to run all tests that are suitable for the @@ -5758,13 +5758,13 @@ The order you list tests in TEST_SUITES - is important. - The order influences test dependencies. + is important and influences test dependencies. Consequently, tests that depend on other tests should be added after the test on which they depend. - For example, since ssh depends on the - ping test, ssh - needs to come after ping in the list. + For example, since the ssh test + depends on the + ping test, "ssh" needs to come after + "ping" in the list. The test class provides no re-ordering or dependency handling. Each module can have multiple classes with multiple test @@ -5887,7 +5887,7 @@ following attributes: d: - The BitBake data store, which allows you to + The BitBake datastore, which allows you to use stuff such as oeRuntimeTest.tc.d.getVar("VIRTUAL-RUNTIME_init_manager"). -- cgit v1.2.3-54-g00ecf