Files
@ 712a32f1026b
Branch filter:
Location: kallithea/docs/api/models.rst - annotation
712a32f1026b
632 B
text/prs.fallenstein.rst
tests: api: fix intertest dependency on repository locking
In test classes based on unittest, tests are executed in alphabetical order.
In test classes based on pytest, tests are executed in the order they are
specified. This difference revealed a problem in the API tests:
- test_api_lock_repo_lock_optional_locked locks the test repository
- test_api_get_locks_regular_user gets the current locks and expects it to
be empty
With unittest as base class, this worked fine because the 'get_locks' group
of tests are executed before the 'lock_repo' group (alphabetical order).
Using a real pytest-based test class, the order is swapped and the locked
repository from the first test invalidates the preconditions of the second
test.
Fix this specific problem by releasing the lock from
test_api_lock_repo_lock_optional_locked.
This commit does not fix other interdependencies between tests. For example,
test_api_lock_repo_lock_optional_locked expects the existing lock state to
be 'locked' but did not lock the repo itself; instead it expects a previous
test to have locked. In practice, this is
test_api_lock_repo_lock_aquire_optional_userid.
A full solution would make each test fully self contained so that tests can
be executed in random order. The pytest extension pytest-random can help
detecting these problems.
In test classes based on unittest, tests are executed in alphabetical order.
In test classes based on pytest, tests are executed in the order they are
specified. This difference revealed a problem in the API tests:
- test_api_lock_repo_lock_optional_locked locks the test repository
- test_api_get_locks_regular_user gets the current locks and expects it to
be empty
With unittest as base class, this worked fine because the 'get_locks' group
of tests are executed before the 'lock_repo' group (alphabetical order).
Using a real pytest-based test class, the order is swapped and the locked
repository from the first test invalidates the preconditions of the second
test.
Fix this specific problem by releasing the lock from
test_api_lock_repo_lock_optional_locked.
This commit does not fix other interdependencies between tests. For example,
test_api_lock_repo_lock_optional_locked expects the existing lock state to
be 'locked' but did not lock the repo itself; instead it expects a previous
test to have locked. In practice, this is
test_api_lock_repo_lock_aquire_optional_userid.
A full solution would make each test fully self contained so that tests can
be executed in random order. The pytest extension pytest-random can help
detecting these problems.
64a5386216c5 bb35ad076e2f 17c9393e9645 22a3fa3c4254 bb35ad076e2f bb35ad076e2f 7e5f8c12a3fc bb35ad076e2f 8b8edfc25856 7e5f8c12a3fc 9da24750f563 8b8edfc25856 7e5f8c12a3fc 8b8edfc25856 9da24750f563 7e5f8c12a3fc bb35ad076e2f 9da24750f563 7e5f8c12a3fc 8b8edfc25856 9da24750f563 7e5f8c12a3fc 8b8edfc25856 bb35ad076e2f 499c513967a1 9da24750f563 8b8edfc25856 7e5f8c12a3fc bb35ad076e2f 8b8edfc25856 7e5f8c12a3fc 8b8edfc25856 8b8edfc25856 499c513967a1 8b8edfc25856 | .. _models:
========================
The :mod:`models` module
========================
.. automodule:: kallithea.model
:members:
.. automodule:: kallithea.model.comment
:members:
.. automodule:: kallithea.model.notification
:members:
.. automodule:: kallithea.model.permission
:members:
.. automodule:: kallithea.model.repo_permission
:members:
.. automodule:: kallithea.model.repo
:members:
.. automodule:: kallithea.model.repo_group
:members:
.. automodule:: kallithea.model.scm
:members:
.. automodule:: kallithea.model.user
:members:
.. automodule:: kallithea.model.user_group
:members:
|