:orphan:
:py:mod:`oioioi.rankings.tests`
===============================
.. py:module:: oioioi.rankings.tests
Module Contents
---------------
Classes
~~~~~~~
.. autoapisummary::
oioioi.rankings.tests.StatementHiderForContestController
oioioi.rankings.tests.TestRankingViews
oioioi.rankings.tests.MockRankingController
oioioi.rankings.tests.MockRankingContestController
oioioi.rankings.tests.TestRecalc
oioioi.rankings.tests.TestRankingsdFrontend
oioioi.rankings.tests.TestResultColorClassFilter
Attributes
~~~~~~~~~~
.. autoapisummary::
oioioi.rankings.tests.VISIBLE_TASKS
oioioi.rankings.tests.HIDDEN_TASKS
oioioi.rankings.tests.USER_CELL_PATTERN
oioioi.rankings.tests.USER_CELL_PATTERN_LEFT
.. py:data:: VISIBLE_TASKS
:annotation: = ['zad1', 'zad2']
.. py:data:: HIDDEN_TASKS
:annotation: = ['zad3', 'zad4']
.. py:data:: USER_CELL_PATTERN
:annotation: =
]*>%s |
.. py:data:: USER_CELL_PATTERN_LEFT
:annotation: = ]*>%s
.. py:class:: StatementHiderForContestController(contest)
Bases: :py:obj:`oioioi.programs.controllers.ProgrammingContestController`
Contains the contest logic and rules.
This is the computerized implementation of the contest's official
rules.
.. py:method:: default_can_see_statement(request_or_context, problem_instance)
.. py:class:: TestRankingViews(methodName='runTest')
Bases: :py:obj:`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.
.. py:attribute:: fixtures
:annotation: = ['test_users', 'test_contest', 'test_full_package', 'test_problem_instance', 'test_submission',...
.. py:method:: test_find_user()
.. py:method:: test_ranking_view()
.. py:method:: test_ranking_csv_view()
.. py:method:: test_invalidate_view()
.. py:class:: MockRankingController(contest)
Bases: :py:obj:`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.
.. py:attribute:: recalculation_result
:annotation: = ['serialized', ['1st', '2nd', '3rd']]
.. py:method:: build_ranking(key)
Serializes data and renders html for given key.
Results are processed using serialize_ranking, and then as many
pages as needed are rendered. Returns a tuple containing serialized
data and a list of strings, that are html code of ranking pages.
.. py:class:: MockRankingContestController(contest)
Bases: :py:obj:`oioioi.programs.controllers.ProgrammingContestController`
Contains the contest logic and rules.
This is the computerized implementation of the contest's official
rules.
.. py:method:: ranking_controller()
.. py:class:: TestRecalc(methodName='runTest')
Bases: :py:obj:`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.
.. py:attribute:: fixtures
:annotation: = ['test_users', 'test_contest', 'test_full_package', 'test_problem_instance', 'test_submission',...
.. py:method:: test_empty()
.. py:method:: test_simple_flow()
.. py:method:: test_simple_invalidate()
.. py:method:: test_invalidate_preferences_saved()
.. py:method:: test_null_checking()
.. py:class:: TestRankingsdFrontend(methodName='runTest')
Bases: :py:obj:`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.
.. py:attribute:: fixtures
:annotation: = ['test_users', 'test_contest', 'test_full_package', 'test_problem_instance', 'test_submission',...
.. py:method:: test_first_ranking_view()
.. py:method:: test_display_ranking()
.. py:method:: test_display_outdated()
.. py:class:: TestResultColorClassFilter(methodName='runTest')
Bases: :py:obj:`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.
.. py:method:: test_integer_scores()
.. py:method:: test_pa_scores()
.. py:method:: _test_scores(score_multiply, score_class_factory)
.. py:method:: pa_score_factory(int_score)
:staticmethod:
.. py:method:: test_empty_scores()
.. py:method:: check_score_color(int_score, color_class_name, score_class_factory)
|