: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)