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
# Now you can run test commands trough make targets, or prefix the rest of commands with `pdm run`, eg. `pdm run make test`
66
+
# Now you can run test commands trough make targets, or prefix the rest of commands with `uv run`, eg. `uv run make test`
67
67
68
68
# run unit tests
69
69
make unit-tests
@@ -173,114 +173,7 @@ Static security check is performed by _Bandit_ tool. The check can be started by
173
173
```
174
174
make security-check
175
175
```
176
-
## Testing
177
176
178
-
Two groups of software tests are used in this repository, each group from the test suite having different granularity. These groups are designed to represent three layers:
179
-
180
-
1. Unit Tests
181
-
1. Integration Tests
182
-
183
-
Unit tests followed by integration and e2e tests can be started by using the following command:
184
-
185
-
```
186
-
make test
187
-
```
188
-
189
-
It is also possible to run just one selected group of tests:
190
-
191
-
```
192
-
make test-unit Run the unit tests
193
-
make test-integration Run integration tests tests
194
-
make test-e2e Run end to end tests
195
-
```
196
-
197
-
All tests are based on the [Pytest framework](https://docs.pytest.org/en/) and code coverage is measured by the plugin [pytest-cov](https://github.com/pytest-dev/pytest-cov). For mocking and patching, the [unittest framework](https://docs.python.org/3/library/unittest.html) is used.
198
-
199
-
Currently code coverage threshold for integration tests is set to 60%. This value is specified directly in Makefile, because the coverage threshold is different from threshold required for unit tests.
200
-
201
-
As specified in Definition of Done, new changes need to be covered by tests.
202
-
203
-
204
-
205
-
### Tips and hints for developing unit tests
206
-
207
-
#### Patching
208
-
209
-
**WARNING**:
210
-
Since tests are executed using Pytest, which relies heavily on fixtures,
211
-
we discourage use of `patch` decorators in all test code, as they may interact with one another.
212
-
213
-
It is possible to use patching inside the test implementation as a context manager:
214
-
215
-
```python
216
-
deftest_xyz():
217
-
with patch("ols.config", new=Mock()):
218
-
...
219
-
...
220
-
...
221
-
```
222
-
223
-
-`new=` allow us to use different function or class
224
-
-`return_value=` allow us to define return value (no mock will be called)
225
-
226
-
227
-
#### Verifying that some exception is thrown
228
-
229
-
Sometimes it is needed to test whether some exception is thrown from a tested function or method. In this case `pytest.raises` can be used:
The Llama Stack can be run as a standalone server and accessed via its the REST
80
77
API. However, instead of direct communication via the REST API (and JSON
81
78
format), there is an even better alternative. It is based on the so-called
82
79
Llama Stack Client. It is a library available for Python, Swift, Node.js or
83
80
Kotlin, which "wraps" the REST API stack in a suitable way, which is easier for
84
81
many applications.
85
82
83
+

84
+
86
85
## Llama Stack as separate server
87
86
88
87
If Llama Stack runs as a separate server, the Lightspeed service needs to be configured to be able to access it. For example, if server runs on localhost:8321, the service configuration should look like:
@@ -311,10 +310,19 @@ If this configuration file does not exist, you will be prompted to specify API t
0 commit comments