You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/reference/contributing/connectivity/MeshInterface.md
+3-1Lines changed: 3 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -66,7 +66,9 @@ The following steps describe how you can create a new RF driver:
66
66
67
67
1. Check with an RF sniffer tool that you can see RF packets transmitted when you start your device. The 6LoWPAN bootstrap should start with IEEE 802.15.4 Beacon Request packets.
68
68
69
-
1. Verify the functionality of your implementation using the [Nanostack RF driver test application](https://github.com/ARMmbed/nanostack-rf-driver-tester). (This is currently only available to Mbed OS Partners.)
69
+
1. Verify the functionality of your implementation by running the Nanostack RF driver testcase set in the Mbed OS repository:
Copy file name to clipboardExpand all lines: docs/tools/offline/cli-test-debug.md
+80-27Lines changed: 80 additions & 27 deletions
Original file line number
Diff line number
Diff line change
@@ -2,23 +2,31 @@
2
2
3
3
Use the `mbed test` command to compile and run tests.
4
4
5
+
There are two testing frameworks: Greentea and Icetea. Greentea provides tests designed for driver porting and target verification. Icetea provides and manages tests for multiple devices at the same time. For example, you can test the network setup for a server and multiple clients, simultaneously controlling them from the test environment.
6
+
5
7
The arguments to `test` are:
6
-
*`-m <MCU>` to select a target for the compilation. If `detect` or `auto` parameter is passed, then Mbed CLI will attempt to detect the connected target and compile against it.
7
-
*`-t <TOOLCHAIN>` to select a toolchain (of those defined in `mbed_settings.py`, see above), where `toolchain` can be either `ARM` (Arm Compiler 5), `GCC_ARM` (GNU Arm Embedded), or `IAR` (IAR Embedded Workbench for Arm).
8
-
*`--compile-list` to list all the tests that can be built.
9
-
*`--run-list` to list all the tests that can be run (they must be built first).
10
-
*`--compile` to only compile the tests.
11
-
*`--run` to only run the tests.
12
-
*`-n <TESTS_BY_NAME>` to limit the tests built or run to a comma separated list (ex. test1,test2,test3).
13
-
*`--source <SOURCE>` to select the source directory. Default is `.` (the current directory). You can specify multiple source locations, even outside the program tree.
14
-
*`--build <BUILD>` to select the build directory. Default: `BUILD/` inside your program.
15
-
*`--profile <PATH_TO_BUILD_PROFILE>` to select a path to a build profile configuration file. Example: `mbed-os/tools/profiles/debug.json`.
16
-
*`-c or --clean` to clean the build directory before compiling.
17
-
*`--test-spec <TEST_SPEC>` to set the path for the test spec file used when building and running tests (the default path is the build directory).
18
-
*`-v` or `--verbose` for verbose diagnostic output.
19
-
*`-vv` or `--very_verbose` for very verbose diagnostic output.
20
-
21
-
Invoke `mbed test`:
8
+
9
+
-`-m <MCU>`: to select a target for the compilation. If the `detect` or `auto` parameter is passed, then Mbed CLI will attempt to detect the connected target and compile against it.
10
+
-`-t <TOOLCHAIN>`: to select a toolchain from those defined in `mbed_settings.py`, where `toolchain` can either be `ARM` (Arm Compiler 5), `GCC_ARM` (GNU Arm Embedded), or `IAR` (IAR Embedded Workbench for Arm).
11
+
-`--compile-list`: to list all the tests that can be built.
12
+
-`--run-list`: to list all the tests that can be run, after they have been built.
13
+
-`--compile`: to only compile the tests.
14
+
-`--run`: to only run the tests.
15
+
-`-n <TESTS_BY_NAME>`: to limit the tests built or run to a comma separated list, for example, `test1, test2, test3`.
16
+
-`--source <SOURCE>`: to select the source directory. The default is `.` for the the current directory. You can specify multiple source locations, even outside the program tree.
17
+
-`--build <BUILD>`: to select the build directory. The default is `BUILD/` inside your program.
18
+
-`--profile <PATH_TO_BUILD_PROFILE>`: to select a path to a build profile configuration file, for example, `mbed-os/tools/profiles/debug.json`.
19
+
-`-c or --clean`: to clean the build directory before compiling.
20
+
-`--test-spec <TEST_SPEC>`: to set the path for the test specification file used when building and running tests. The default path is the build directory.
21
+
-`--build-data <BUILD_DATA>`: dumps build_data to this file.
22
+
-`--app-config <APP_CONFIG>`: the path of an app configuration file. The default is to look for `mbed_app.json`.
23
+
-`--test-config <TEST_CONFIG>`: the path or Mbed OS keyword of a test configuration file, for example, `ethernet`, `odin_wifi` or `path/to/config.json`.
24
+
-`--greentea`: to run Greentea tests. As a default, it only runs Greentea tests.
25
+
-`--icetea`: to run Icetea tests. If used without the `--greentea` flag, then it only runs Icetea tests.
26
+
-`-v` or `--verbose`: for verbose diagnostic output.
27
+
-`-vv` or `--very_verbose`: for very verbose diagnostic output.
28
+
29
+
To invoke the `mbed test`:
22
30
23
31
```
24
32
$ mbed test -m K64F -t GCC_ARM
@@ -79,6 +87,33 @@ Test Case:
79
87
Path: .\TESTS\functional\test3
80
88
```
81
89
90
+
For Icetea:
91
+
92
+
```
93
+
$ mbed test -m K64F -t GCC_ARM --icetea --compile-list
94
+
Available Icetea tests for build 'K64F-GCC_ARM', location 'TEST_APPS'
You can find the tests that are available for **running** by using the `--run-list` option:
83
118
84
119
```
@@ -91,21 +126,38 @@ mbedgt: available tests for built 'K64F-ARM', location '.\build\tests\K64F\ARM'
91
126
test 'TESTS-functional-test3'
92
127
```
93
128
129
+
For Icetea:
130
+
131
+
```
132
+
$ mbed test -m K64F -t GCC_ARM --icetea --run-list
133
+
Available Icetea tests for build 'K64F-GCC_ARM', location 'TEST_APPS'
134
+
test 'UDPSOCKET_BIND_PORT'
135
+
test 'TCPSOCKET_BIND_PORT'
136
+
test 'TCPSERVER_ACCEPT'
137
+
test 'TCPSOCKET_ECHOTEST_BURST_SHORT'
138
+
```
139
+
94
140
### Compiling and running tests
95
141
96
-
You can specify to only **build** the tests by using the `--compile` option:
142
+
You can specify that the tests only **build** by using the `--compile` option:
97
143
98
144
```
99
145
$ mbed test -m K64F -t GCC_ARM --compile
100
146
```
101
147
102
-
You can specify to only **run** the tests by using the `--run` option:
148
+
For Icetea, only the test applications are built:
149
+
150
+
```
151
+
$ mbed test -m K64F -t GCC_ARM --compile --icetea
152
+
```
153
+
154
+
You can specify that the tests only **run** by using the `--run` option:
103
155
104
156
```
105
157
$ mbed test -m K64F -t GCC_ARM --run
106
158
```
107
159
108
-
If you don't specify any of these, `mbed test`will first compile all available tests and then run them.
160
+
If you don't specify any of these, `mbed test` first compiles all available tests and then runs them.
109
161
110
162
### Limiting the test scope
111
163
@@ -115,7 +167,7 @@ You can limit the scope of the tests built and run by using the `-n` option. Thi
115
167
$ mbed test -m K64F -t GCC_ARM -n TESTS-functional-test1,TESTS-functional-test2
116
168
```
117
169
118
-
You can use the wildcard character `*` to run a group of tests that share a common prefix without specifying each test individually. For instance, if you only want to run the three tests `TESTS-functional-test1`, `TESTS-functional-test2` and `TESTS-functional-test3`, but you have other tests in your project, you can run:
170
+
You can use the wildcard character `*` to run a group of tests that share a common prefix without specifying each test individually. For instance, if you only want to run the three tests,`TESTS-functional-test1`, `TESTS-functional-test2` and `TESTS-functional-test3`, but you have other tests in your project, you can run:
119
171
120
172
```
121
173
$ mbed test -m NUCLEO_F429ZI -t GCC_ARM -n TESTS-functional*
@@ -154,16 +206,17 @@ mbed-os-program
154
206
| ....
155
207
```
156
208
157
-
As shown above, tests exist inside `TESTS\testgroup\testcase\` directories. Please note that `TESTS` is a special uppercase directory that is excluded from module sources while compiling.
209
+
As shown above, tests exist inside `TESTS\testgroup\testcase\` directories. Please note that `TESTS` is a special upper-case directory that is excluded from module sources while compiling.
158
210
159
-
<spanclass="notes">**Note:**`mbed test` does not work in applications that contain a `main` function that is outside of a `TESTS` directory.</span>
211
+
<spanclass="notes">**Note:**`mbed test` does not work in applications that contain a `main` function that is outside of a `TESTS` directory.</span>
160
212
161
213
### Troubleshooting
162
214
163
-
#### Unable to import Mercurial (mbed.org) programs or libraries.
164
-
1. Check whether you have Mercurial installed in your system path by running `hg` in command prompt. If you're receiving "command not found" or a similar message, then you need to install Mercurial, and add it to your system path.
215
+
#### Import Mercurial (mbed.org) programs or libraries
216
+
217
+
1. Check whether you have Mercurial installed in your system path by running `hg` in the command prompt. If you are receiving "command not found" or a similar message, then you need to install Mercurial and add it to your system path.
218
+
1. Try to clone a Mercurial repository directly. For example, `hg clone https://developer.mbed.org/teams/mbed/code/mbed_blinky/`. If you receive an error similar to `abort: error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.:590)`, then your system certificates are out of date. You need to update your system certificates and possibly add the host certificate fingerprint of `mbed.com` and `mbed.org`. You can read more about Mercurial's [certificate management](https://www.mercurial-scm.org/wiki/CACertificates).
165
219
166
-
2. Try to clone a Mercurial repository directly. For example, `hg clone https://developer.mbed.org/teams/mbed/code/mbed_blinky/`. If you receive an error similar to `abort: error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.:590)`, then your system certificates are out of date. You need to update your system certificates and possibly add the host certificate fingerprint of `mbed.com` and `mbed.org`. You can read more about Mercurial's [certificate management](https://www.mercurial-scm.org/wiki/CACertificates).
220
+
#### Various issues when running Mbed CLI in the Cygwin environment
167
221
168
-
#### Various issues when running Mbed CLI in Cygwin environment
169
-
Currently Mbed CLI is not compatible with Cygwin environment and [cannot be executed inside it](https://github.com/ARMmbed/mbed-cli/issues/299).
222
+
Mbed CLI is not currently compatible with the Cygwin environment and [cannot be executed inside it](https://github.com/ARMmbed/mbed-cli/issues/299).
Icetea is an automated testing framework for Mbed development. It automates the process of flashing Mbed boards, running tests and accumulating test results into reports. Developers use it for local development, as well as automation in a Continuous Integration environment.
4
+
5
+
When testing Mbed OS, Icetea allows you to execute commands remotely by using the command-line interface in a device under test (DUT). The interface between the test framework and a DUT might be, for example, UART or stdio.
6
+
7
+
More detailed documentation on the tool is available [in rst format](https://github.com/ARMmbed/icetea/tree/master/doc-source) and [in markdown format](https://github.com/ARMmbed/icetea/tree/master/doc).
8
+
9
+
### Prerequisites
10
+
11
+
Icetea supports Linux (Ubuntu preferred), Windows and OS X. Our main target is Linux.
12
+
13
+
You need `pip` to install Icetea.
14
+
15
+
Icetea supports both Python 2.7 and 3.5, or later. Some OS specific prerequisites are listed below:
16
+
17
+
- Linux.
18
+
- python-dev and python-lxml:
19
+
`sudo apt-get install python-dev python-lxml`
20
+
- To run test cases with hardware in Linux, without sudo rights:
21
+
22
+
```
23
+
sudo usermod -a -G dialout username
24
+
Log out & log in back to Linux
25
+
```
26
+
27
+
This command adds the user `username` to the `dialout` group and grants the required permissions to the USB ports.
- python-lxml installation on Windows usually requires build tools. You can, however, install it from prebuilt binaries.
37
+
- Search the internet for a binary for your system.
38
+
- Navigate to the directory where you downloaded the binary, and install it with `pip install <insert_file_name>`
39
+
- You can also follow [these instructions](http://lxml.de/installation.html#installation) instead.
40
+
41
+
#### Optional
42
+
43
+
If you wish to decorate your console log with colors, install the `coloredlogs` module by using pip: `pip install coloredlogs`. There have been issues with `coloredlogs` installation on Windows. There are no alternative solutions for this at the moment.
44
+
45
+
### Installation
46
+
47
+
`> pip install icetea`
48
+
49
+
### Use
50
+
51
+
To display the help page:
52
+
53
+
`icetea --help`
54
+
55
+
To list all local test cases from the examples subfolder:
56
+
57
+
`icetea --list --tcdir examples`
58
+
59
+
To print the Icetea version:
60
+
61
+
`icetea --version`
62
+
63
+
#### Typical use
64
+
65
+
All of the commands described below might also require other commands, depending on the test case.
66
+
67
+
**Running test cases by using the `tc` argument**
68
+
69
+
`> icetea --tc <test case name> --tcdir <test case search path>`
70
+
71
+
To run all existing test cases from the `examples` folder:
72
+
73
+
`> icetea --tc all --tcdir examples`
74
+
75
+
**Running an example test case with hardware**
76
+
77
+
This example requires a compatible board connected to the computer and an application binary for the board. The test case below is available in [the Icetea GitHub repository](https://github.com/ARMmbed/icetea/blob/master/examples/test_cmdline.py).
78
+
79
+
`> icetea --tc test_cmdline --tcdir examples --type hardware --bin <path to a binary>`
80
+
81
+
**Using metadata filters**
82
+
83
+
To run all test cases with test-type regression in the metadata:
84
+
85
+
`> icetea --testtype regression --tcdir <test case search path>`
86
+
87
+
The following metadata filters are available:
88
+
89
+
- test type (`--testtype`).
90
+
- test subtype (`--subtype`).
91
+
- feature (`--feature`).
92
+
- test case name (`--tc`).
93
+
- tested component (`--component`).
94
+
- test case folder (`--group`).
95
+
96
+
**Running a premade suite**
97
+
98
+
Icetea supports a suite file that describes a number of test cases in `json` format:
99
+
100
+
`> icetea --suite <suite file name> --tcdir <test case search path> --suitedir <path to suite directory>`
101
+
102
+
**Enabling debug level logging**
103
+
104
+
Use `-v` or `-vv` arguments to control logging levels. `-v` increases the framework's logging level to debug (default is info), the level of logging in certain plugins and external components to info (default is warning). `--vv` increases the level of logging on all Icetea loggers to debug.
105
+
106
+
#### Creating a test case
107
+
108
+
Icetea test cases are implemented as Python classes that inherit the bench object available in the `icetea_lib.bench` module. The test case needs to have an initialization function that defines the metadata and a case function that implements the test sequence. There are two optional functions: setup and teardown.
109
+
110
+
An example test case is shown below:
111
+
112
+
```
113
+
"""
114
+
Copyright 2017 ARM Limited
115
+
Licensed under the Apache License, Version 2.0 (the "License");
116
+
you may not use this file except in compliance with the License.
117
+
You may obtain a copy of the License at
118
+
119
+
http://www.apache.org/licenses/LICENSE-2.0
120
+
121
+
Unless required by applicable law or agreed to in writing, software
122
+
distributed under the License is distributed on an "AS IS" BASIS,
123
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
124
+
See the License for the specific language governing permissions and
125
+
limitations under the License.
126
+
"""
127
+
128
+
from icetea_lib.bench import Bench
129
+
130
+
131
+
class Testcase(Bench):
132
+
def __init__(self):
133
+
Bench.__init__(self,
134
+
name="example_test",
135
+
title="Example test",
136
+
status="development",
137
+
purpose="Show example of a test",
138
+
component=["examples"],
139
+
type="smoke",
140
+
requirements={
141
+
"duts": {
142
+
'*': {
143
+
"count": 1,
144
+
"type": "hardware"
145
+
}
146
+
}
147
+
}
148
+
)
149
+
150
+
def setup(self):
151
+
# nothing for now
152
+
pass
153
+
154
+
155
+
def case(self):
156
+
self.command(1, "echo hello world", timeout=5)
157
+
self.command("help")
158
+
159
+
def teardown(self):
160
+
# nothing for now
161
+
pass
162
+
```
163
+
164
+
### License
165
+
166
+
For licensing details, please see the [license agreement](https://github.com/ARMmbed/icetea/blob/master/LICENSE).
0 commit comments