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: tests/README.md
+35-2
Original file line number
Diff line number
Diff line change
@@ -106,7 +106,14 @@ BSTest library also contains a Python script which can "talk" to the ESP8266 boa
106
106
107
107
### Test configuration
108
108
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
+
110
117
111
118
### Building and running the tests
112
119
@@ -135,15 +142,41 @@ Here are some of the supported targets:
135
142
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:
136
143
137
144
```python
138
-
from mock_decorators import setup, teardown
145
+
from mock_decorators import setup, teardown, setenv, request_env
139
146
140
147
@setup('WiFiClient test')
141
148
def setup_wificlient_test(e):
142
149
# 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))
143
153
144
154
@teardown('WiFiClient test')
145
155
def teardown_wificlient_test(e):
146
156
# 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
0 commit comments