Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spelling fixes and general readability improvements for TEST_APPS documentation #8067

Merged
merged 2 commits into from
Sep 17, 2018
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 37 additions & 27 deletions TEST_APPS/readme.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,57 +2,66 @@

### Structure

mbed-os has a folder called TEST_APPS that contains everything related to Icetea testing.
There are currently 3 folders:
Mbed OS has a folder called `TEST_APPS` that contains everything related to Icetea testing.

- device - contains all the different test applications you can flash to your board
- icetea-plugins - contains plugins that are being used by some of the testcases, needed for the test execution
- testcases - contains Icetea testcases written in Python
There are currently three folders:

The testcases depends on test applications
- `device` - contains all the different test applications you can flash to your board.
- `icetea_plugins` - contains plugins that are being used by some of the testcases, needed for the test execution.
- `testcases` - contains Icetea testcases written in Python.

The testcases depend on test applications.

### Preparing your work environment

#### Prerequisities
#### Prerequisites

You need Icetea and mbed-cli that supports Icetea, installed.
You need Icetea and version 1.8.0 or higher of Mbed CLI installed.

#### Selecting the network interface to use

Depending on a device, there might be a default network interface type defined in the mbed-os/targets/targets.json, which is used to locate a test-config file by default.
If there is not, or you want to use a different interface than the default, you need to provide a relevant test-config -file to the mbed test with --test-config option.
The test-config file contains the necessary information for the test application, there are some test-config files located under mbed-os/tools/test_configs.
Devices which have their network drivers residing inside mbed-os can use generic test_configs like HeapBlockDeviceAndEthernetInterface.json and HeapBlockDeviceAndWifiInterface.json. Otherwise you need to use a device specific test-config.
Depending on the device, there might be a default network interface type defined in `mbed-os/targets/targets.json`, which you can use to locate a default test-config file.

If the default network interface type is not defined or you want to use a different interface than the default, you need to provide a test-config file to the mbed test with `--test-config` option.

The test-config file contains the necessary information for the test application. There are some test-config files located under `mbed-os/tools/test_configs`.

Devices that have their network drivers residing inside `mbed-os` can use generic `test_configs`, such as `HeapBlockDeviceAndEthernetInterface.json` and `HeapBlockDeviceAndWifiInterface.json`. Otherwise, you need to use a device-specific test-config.

### Running the tests

Now that the interface has been selected you can run the icetea tests from the mbed-os root on your command line by
Now that you have selected the interface, you can run the Icetea tests from the `mbed-os` root on your command-line by running the following command:

`mbed test -m <target> -t <toolchain> --icetea`

`>mbed test -m <target> -t <toolchain> --icetea`
This command compiles the OS, compiles the test applications, creates a test suite and then starts running the tests.

This command will compile the mbed-os, then compiles the test applications, creates a test suite and then starts running the tests.
If you only want to run some specific tests, you can use the `-n` option. You can choose multiple tests by separating them with a comma (`,`):

If you want only to run some specific tests, you can use the -n -option. You can list multiple tests by separating them by comma (,).
`mbed test -m <target> -t <toolchain> --icetea -n test1,test2`

`>mbed test -m <target> -t <toolchain> --icetea -n test1,test2`
#### Running the tests with a specific test-config

#### Running the tests with specifig test-config
Some devices may offer multiple network interfaces to operate with. For example, `UBLOX_EVK_ODIN_W2` offers ethernet and Wi-Fi capabilities.

Some devices may offer multiple network interfaces to operate with. For example, UBLOX_EVK_ODIN_W2 offers ethernet and Wi-Fi capabilities.
The tests can be run for either one of those using already existing test-config -files.

To run the tests with Wi-Fi interface:
`>mbed test -m UBLOX_EVK_ODIN_W2 -t <toolchain> --icetea --test-config tools/test_configs/HeapBlockDeviceAndWifiInterface.json`
To run the tests with the Wi-Fi interface:

To run the tests with ethernet interface:
`>mbed test -m UBLOX_EVK_ODIN_W2 -t <toolchain> --icetea --test-config tools/test_configs/HeapBlockDeviceAndEthernetInterface.json`
`mbed test -m UBLOX_EVK_ODIN_W2 -t <toolchain> --icetea --test-config tools/test_configs/HeapBlockDeviceAndWifiInterface.json`

To run the tests with the ethernet interface:

`mbed test -m UBLOX_EVK_ODIN_W2 -t <toolchain> --icetea --test-config tools/test_configs/HeapBlockDeviceAndEthernetInterface.json`

#### Providing Wi-Fi access point information

If you are using Wi-Fi interface for running the tests, you need to provide also information about the used access point.
If you are using the Wi-Fi interface for running the tests, you need to also provide information about the used access point.

The information can be provided in the used test-config file.

Example of access point information:

```
"target_overrides": {
"*": {
Expand All @@ -66,7 +75,7 @@ Example of access point information:

### Test results

Icetea prints the results from the test run to the command line, and the final result looks similar to this.
Icetea prints the results from the test run to the command-line, and the final result looks similar to this:

```
+--------------------------------+---------+-------------+-------------+-----------+----------+
Expand All @@ -89,5 +98,6 @@ Icetea prints the results from the test run to the command line, and the final r
+---------------+----------------+
```

The results from the tests can also be found in the mbed-os/log folder.
You probably want to add the log folder to your .mbedignore file to prevent issues with build commands becoming too long over the time.
You can also find the results from the tests in the `mbed-os/log` folder.

You probably want to add the log folder to your `.mbedignore` file to prevent issues with build commands becoming too long over the time.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why build command touch even log files? Could it be ignored by default?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SeppoTakalo @OPpuolitaival Could y'all address this question?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the concern is that mbed-os/log adds another include directory to the already long list of include directories. As long as no subdirectories are added to mbed-os/log, I think it'd be safe to remove this section in the docs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we know that its always mbed-os/log then I would be happy to add that into .mbedignore file, just to be safe.