paulmataruso/zulip
1
0
Fork 0
mirror of https://github.com/zulip/zulip.git synced 2025-11-04 05:53:43 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: Document TEST_WORKER_DIR.

Browse Source
This commit is contained in:
Tim Abbott
2019-07-12 17:52:08 -07:00
parent 0e3fddbc6e
commit 86f762bc75
1 changed files with 21 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
docs/testing/testing-with-django.md
View File

@@ -112,35 +112,37 @@ Here are some example action methods that tests may use for data setup:
### Testing code that accesses the filesystem
Some of our tests (e.g. `test_upload.py` tests for
`LocalUploadBackend` and the data import tests) test code that needs
to write and then read back files from the filesystem. Doing this
correctly requires care to avoid leaking files after every test (which
are clutter and can eventually run the development environment out of
disk) or interacting with other parallel processes of this
`test-backend` run (or another `test-backend` run). Generally, the
best practices are for tests to:
Some tests need to access the filesystem (e.g. `test_upload.py` tests
for `LocalUploadBackend` and the data import tests). Doing
this correctly requires care to avoid problems like:
* Leaking files after every test (which are clutter and can eventually
run the development environment out of disk) or
* Interacting with other parallel processes of this `test-backend` run
(or another `test-backend` run), or with later tests run by this
process.
* Place any files created by the test under the dedicated directory
tree for `test-backend` that is managed by the current development
environment (`var/<uuid>/test-backend/run_1234567/worker_N`).
To avoid these problems, you can do the following:
* Use a subdirectory of `settings.TEST_WORKER_DIR`; this is a
subdirectory of `/var/<uuid>/test-backend` that is unique to the
test worker thread and will be automatically deleted when the
relevant `test-backend` process finishes.
* Delete any files created by the test in the test class's `tearDown`
method (which runs even if the test fails).
method (which runs even if the test fails); this is valuable to
avoid conflicts with other tests run later by the same test process.
Our common testing infrastructure handles some of this for you,
e.g. it replaces `settings.LOCAL_UPLOADS_DIR` for each test process
with a unique path under `/var/<uuid>/test-backend`. And
`UploadSerializeMixin` manages some of the cleanup work for
`test_upload.py`. But it's worth testing `find var/*/test-backend`
before and after you run a new test to make sure we don't leak new
files.
(Eventually we'll move this into a check in CI).
`test_upload.py`.
### Testing with mocks
This section is a beginner's guide to mocking with Python's `unittest.mock` library. It will give you answers
to the most common questions around mocking, and a selection of commonly used mocking techniques.
This section is a beginner's guide to mocking with Python's
`unittest.mock` library. It will give you answers to the most common
questions around mocking, and a selection of commonly used mocking
techniques.
#### What is mocking?