oioioi.rankings.tests
¶
Module Contents¶
Classes¶
Contains the contest logic and rules. |
|
Similar to TransactionTestCase, but use transaction.atomic() to achieve |
|
Ranking system uses two types of keys: "partial key"s and "full key"s. |
|
Contains the contest logic and rules. |
|
Similar to TransactionTestCase, but use transaction.atomic() to achieve |
|
Similar to TransactionTestCase, but use transaction.atomic() to achieve |
|
Similar to TransactionTestCase, but use transaction.atomic() to achieve |
Attributes¶
- class oioioi.rankings.tests.StatementHiderForContestController(contest)[source]¶
Bases:
oioioi.programs.controllers.ProgrammingContestController
Contains the contest logic and rules.
This is the computerized implementation of the contest’s official rules.
- class oioioi.rankings.tests.TestRankingViews(methodName='runTest')[source]¶
Bases:
oioioi.base.tests.TestCase
Similar to TransactionTestCase, but use transaction.atomic() to achieve test isolation.
In most situations, TestCase should be preferred to TransactionTestCase as it allows faster execution. However, there are some situations where using TransactionTestCase might be necessary (e.g. testing some transactional behavior).
On database backends with no transaction support, TestCase behaves as TransactionTestCase.
- class oioioi.rankings.tests.MockRankingController(contest)[source]¶
Bases:
oioioi.rankings.controllers.DefaultRankingController
Ranking system uses two types of keys: “partial key”s and “full key”s. Please note that full keys are abbreviated in the code as “key”s.
A pair (request, partial_key) should allow to build a full key, while a partial_key can always be extracted from the full key. partial keys identify the rounds to display and are used everywhere outside controllers and rankingsd (e.g. in views and urls). However, the actual ranking contents can depend on many other factors, like user permissions. This was the reason for introduction of full keys, which are always sufficient to choose the right data for serialization and display.
- class oioioi.rankings.tests.MockRankingContestController(contest)[source]¶
Bases:
oioioi.programs.controllers.ProgrammingContestController
Contains the contest logic and rules.
This is the computerized implementation of the contest’s official rules.
- class oioioi.rankings.tests.TestRecalc(methodName='runTest')[source]¶
Bases:
oioioi.base.tests.TestCase
Similar to TransactionTestCase, but use transaction.atomic() to achieve test isolation.
In most situations, TestCase should be preferred to TransactionTestCase as it allows faster execution. However, there are some situations where using TransactionTestCase might be necessary (e.g. testing some transactional behavior).
On database backends with no transaction support, TestCase behaves as TransactionTestCase.
- class oioioi.rankings.tests.TestRankingsdFrontend(methodName='runTest')[source]¶
Bases:
oioioi.base.tests.TestCase
Similar to TransactionTestCase, but use transaction.atomic() to achieve test isolation.
In most situations, TestCase should be preferred to TransactionTestCase as it allows faster execution. However, there are some situations where using TransactionTestCase might be necessary (e.g. testing some transactional behavior).
On database backends with no transaction support, TestCase behaves as TransactionTestCase.
- class oioioi.rankings.tests.TestResultColorClassFilter(methodName='runTest')[source]¶
Bases:
oioioi.base.tests.TestCase
Similar to TransactionTestCase, but use transaction.atomic() to achieve test isolation.
In most situations, TestCase should be preferred to TransactionTestCase as it allows faster execution. However, there are some situations where using TransactionTestCase might be necessary (e.g. testing some transactional behavior).
On database backends with no transaction support, TestCase behaves as TransactionTestCase.