Skip to content

Commit dae30ec

Browse files
committed
host side tests: update documentation about environment variables
1 parent 1acaa8b commit dae30ec

File tree

1 file changed

+35
-2
lines changed

1 file changed

+35
-2
lines changed

Diff for: tests/README.md

+35-2
Original file line numberDiff line numberDiff line change
@@ -106,7 +106,14 @@ BSTest library also contains a Python script which can "talk" to the ESP8266 boa
106106
107107
### Test configuration
108108
109-
Some tests need to connect to WiFi AP or to the PC running the tests. This configuration should be set in tests/device/libraries/test_config/test_config.h. This file is not tracked in Git. Create it by copying from tests/device/libraries/test_config/test_config.h.template, and modifying settings in that file.
109+
Some tests need to connect to WiFi AP or to the PC running the tests. In the test code, this configuration is read from environment variables (the ones set using C `getenv`/`setenv` functions). There are two ways environment variables can be set.
110+
111+
- Environment variables which apply to all or most of the tests can be defined in `tests/device/test_env.cfg` file. This file is not present in Git by default. Make a copy of `tests/device/test_env.cfg.template` and change the values to suit your environment.
112+
113+
- Environment variables which apply to a specific test can be set dynamically by the `setup` host side helper (see section below). This is done using `setenv` function defined in `mock_decorators`.
114+
115+
Environment variables can also be used to pass some information from the test code to the host side helper. To do that, test code can set an environment variable using `setenv` C function. Then the `teardown` host side helper can obtain the value of that variable using `request_env` function defined in `mock_decorators`.
116+
110117
111118
### Building and running the tests
112119
@@ -135,15 +142,41 @@ Here are some of the supported targets:
135142
Some tests running on the device need a matching part running on the host. For example, HTTP client test might need a web server running on the host to connect to. TCP server test might need to be connected to by TCP client running on the host. To support such use cases, for each test file, an optional Python test file can be provided. This Python file defines setup and teardown functions which have to be run before and after the test is run on the device. `setup` and `teardown` decorators bind setup/teardown functions to the test with specified name:
136143
137144
```python
138-
from mock_decorators import setup, teardown
145+
from mock_decorators import setup, teardown, setenv, request_env
139146
140147
@setup('WiFiClient test')
141148
def setup_wificlient_test(e):
142149
# create a TCP server
150+
# pass environment variable to the test
151+
setenv(e, 'SERVER_PORT', '10000')
152+
setenv(e, 'SERVER_IP', repr(server_ip))
143153
144154
@teardown('WiFiClient test')
145155
def teardown_wificlient_test(e):
146156
# delete TCP server
157+
# request environment variable from the test, compare to the expected value
158+
read_bytes = request_env(e, 'READ_BYTES')
159+
assert(read_bytes == '4096')
160+
```
161+
162+
Corresponding test code might look like this:
163+
164+
```c++
165+
166+
TEST_CASE("WiFiClient test", "[wificlient]")
167+
{
168+
const char* server_ip = getenv("SERVER_IP");
169+
int server_port = (int) strtol(getenv("SERVER_PORT"), NULL, 0);
170+
171+
WiFiClient client;
172+
REQUIRE(client.connect(server_ip, server_port));
173+
174+
// read data from server
175+
// ...
176+
177+
// Save the result back so that host side helper can read it
178+
setenv("READ_BYTES", String(read_bytes).c_str(), 1);
179+
}
147180
```
148181
149182

0 commit comments

Comments
 (0)