:orphan: :py:mod:`oioioi.contests.tests.tests` ===================================== .. py:module:: oioioi.contests.tests.tests Module Contents --------------- Classes ~~~~~~~ .. autoapisummary:: oioioi.contests.tests.tests.TestModels oioioi.contests.tests.tests.TestScores oioioi.contests.tests.tests.TestSubmissionListOrder oioioi.contests.tests.tests.TestSubmissionListFilters oioioi.contests.tests.tests.TestUrls oioioi.contests.tests.tests.TestCurrentContest oioioi.contests.tests.tests.TestContestController oioioi.contests.tests.tests.TestContestViews oioioi.contests.tests.tests.TestMySubmissions oioioi.contests.tests.tests.TestManyRounds oioioi.contests.tests.tests.TestMultilingualStatements oioioi.contests.tests.tests.ContestWithoutStatementsController oioioi.contests.tests.tests.TestMySubmissionsContext oioioi.contests.tests.tests.TestSubmitButtonInProblemsList oioioi.contests.tests.tests.TestStatementsVisibility oioioi.contests.tests.tests.BrokenContestController oioioi.contests.tests.tests.TestRejudgeAndFailure oioioi.contests.tests.tests.TestRejudgeTypesView oioioi.contests.tests.tests.TestContestAdmin oioioi.contests.tests.tests.TestAttachments oioioi.contests.tests.tests.TestRoundExtension oioioi.contests.tests.tests.TestPermissions oioioi.contests.tests.tests.TestPermissionsBasicAdmin oioioi.contests.tests.tests.TestProblemsMenuWithQuizzes oioioi.contests.tests.tests.TestSubmissionChangeKind oioioi.contests.tests.tests.TestDeleteSelectedSubmissions oioioi.contests.tests.tests.TestSubmitSelectOneProblem oioioi.contests.tests.tests.TestSubmitSelectManyProblems oioioi.contests.tests.tests.TestDateRegistry oioioi.contests.tests.tests.ContestWithPublicResultsController oioioi.contests.tests.tests.TestPublicResults oioioi.contests.tests.tests.TestContestLinks oioioi.contests.tests.tests.TestPersonalDataUser oioioi.contests.tests.tests.TestUserInfo oioioi.contests.tests.tests.TestProblemInstanceView oioioi.contests.tests.tests.TestReattachingProblems oioioi.contests.tests.tests.TestModifyContest oioioi.contests.tests.tests.TestRegistrationController oioioi.contests.tests.tests.TestAdministeredContests oioioi.contests.tests.tests.TestSubmissionViewWithoutContest oioioi.contests.tests.tests.TestSubmissionAdminWithoutContest oioioi.contests.tests.tests.TestSubmissionsLimitOnListView oioioi.contests.tests.tests.TestSubmissionsLinksOnListView oioioi.contests.tests.tests.TestNoSubmissionsLimitOnListView oioioi.contests.tests.tests.TestAPIGetProblemId oioioi.contests.tests.tests.TestAPISubmitBase oioioi.contests.tests.tests.TestAPIContestSubmit oioioi.contests.tests.tests.TestAPIProblemsetSubmit oioioi.contests.tests.tests.TestManyRoundsNoEnd oioioi.contests.tests.tests.TestRankingVisibility oioioi.contests.tests.tests.TestContestChangeForm oioioi.contests.tests.tests.TestOpenRegistration Functions ~~~~~~~~~ .. autoapisummary:: oioioi.contests.tests.tests.print_contest_id_view oioioi.contests.tests.tests.render_contest_id_view oioioi.contests.tests.tests.failing_handler oioioi.contests.tests.tests.see_limits_on_problems_list oioioi.contests.tests.tests.see_link_for_submission_on_problem_list oioioi.contests.tests.tests.check_ranking_visibility oioioi.contests.tests.tests.set_registration_availability oioioi.contests.tests.tests.check_registration .. py:class:: TestModels(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_fields_autogeneration() .. py:class:: TestScores(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_integer_score() .. py:method:: test_score_field() .. py:method:: test_db_order() .. py:function:: print_contest_id_view(request) .. py:function:: render_contest_id_view(request) .. py:class:: TestSubmissionListOrder(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:: setUp() Hook method for setting up the test fixture before exercising it. .. py:method:: test_default_order() .. py:method:: check_id_order_in_response(response, ids) .. py:method:: test_score_order() .. py:method:: check_ce_order_in_response(response, is_descending, error_msg) .. py:method:: check_order_in_response(response, order, error_msg) .. py:class:: TestSubmissionListFilters(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:: setUp() Hook method for setting up the test fixture before exercising it. .. py:method:: test_all_filters() .. py:class:: TestUrls(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_contest'] .. py:method:: test_make_patterns() .. py:method:: test_reverse() .. py:class:: TestCurrentContest(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_two_empty_contests'] .. py:method:: _test_redirecting_contest_mode() .. py:method:: test_neutral_contest_mode() .. py:method:: test_contest_if_possible_contest_mode() .. py:method:: test_contest_only_contest_mode() .. py:method:: test_namespaced_redirect() .. py:class:: TestContestController(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_order_rounds_by_focus() .. py:class:: TestContestViews(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_recent_contests_list() .. py:method:: test_contest_visibility() .. py:method:: test_submission_view() .. py:method:: test_submissions_permissions() .. py:class:: TestMySubmissions(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_list'] .. py:method:: test_submission_messages() .. py:class:: TestManyRounds(methodName='runTest') Bases: :py:obj:`oioioi.base.tests.TestsUtilsMixin`, :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:: remove_ws(response) :staticmethod: .. py:method:: test_problems_visibility() .. py:method:: test_submissions_visibility() .. py:method:: test_mixin_past_rounds_hidden_during_prep_time() .. py:class:: TestMultilingualStatements(methodName='runTest') Bases: :py:obj:`oioioi.base.tests.TestCase`, :py:obj:`oioioi.filetracker.tests.TestStreamingMixin` 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_extra_statements'] .. py:method:: test_multilingual_statements() .. py:class:: ContestWithoutStatementsController(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:: TestMySubmissionsContext(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'] .. py:method:: test_config() .. py:class:: TestSubmitButtonInProblemsList(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_with_authorized_user() .. py:method:: test_with_unauthorized_user() .. py:method:: test_with_no_submissions_left() .. py:method:: test_with_ended_round() .. py:class:: TestStatementsVisibility(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'] .. py:method:: test_controller() .. py:method:: test_statements_config() .. py:function:: failing_handler(env) .. py:class:: BrokenContestController(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:: fill_evaluation_environ(environ, submission) .. py:class:: TestRejudgeAndFailure(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_rejudge_request() .. py:method:: test_rejudge_and_failure() .. py:method:: test_suspicious_rejudge_request() .. py:class:: TestRejudgeTypesView(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_view() .. py:class:: TestContestAdmin(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'] .. py:method:: test_simple_contest_create_and_change() .. py:method:: test_admin_permissions() .. py:class:: TestAttachments(methodName='runTest') Bases: :py:obj:`oioioi.base.tests.TestCase`, :py:obj:`oioioi.filetracker.tests.TestStreamingMixin` 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'] .. py:method:: test_attachments() .. py:method:: test_pub_date() .. py:class:: TestRoundExtension(methodName='runTest') Bases: :py:obj:`oioioi.base.tests.TestCase`, :py:obj:`oioioi.programs.tests.SubmitFileMixin` 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_extra_rounds'] .. py:method:: test_round_extension() .. py:method:: test_round_extension_admin() .. py:class:: TestPermissions(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:: get_fake_request_factory(contest=None) .. py:method:: setUp() Hook method for setting up the test fixture before exercising it. .. py:method:: test_utils() .. py:method:: test_privilege_manipulation() .. py:method:: test_menu() .. py:class:: TestPermissionsBasicAdmin(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_permissions', 'test_contest', 'test_full_package', 'test_problem_packages',... .. py:method:: setUp() Hook method for setting up the test fixture before exercising it. .. py:method:: test_dashboard() .. py:method:: test_menu() .. py:method:: test_menu_settings() .. py:method:: test_menu_problems() .. py:method:: test_problem_admin() .. py:method:: test_probleminstance_admin() .. py:method:: test_modelsolutions() .. py:method:: test_modelsubmission_source() .. py:method:: test_menu_submissions() .. py:method:: test_menu_problempackages_basicadmin() .. py:method:: test_menu_problempackages_admin() .. py:method:: test_usermenu() .. py:method:: test_usermenu_files() .. py:method:: test_usermenu_submit() .. py:method:: test_usermenu_ranking() .. py:method:: test_usermenu_questions_and_news() .. py:method:: test_show_info_about() .. py:class:: TestProblemsMenuWithQuizzes(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_permissions', 'test_contest', 'test_quiz_problem', 'test_problem_instance',... .. py:method:: test_menu_problems() .. py:class:: TestSubmissionChangeKind(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_multiple_submissions'] .. py:method:: setUp() Hook method for setting up the test fixture before exercising it. .. py:method:: change_kind(submission, kind) .. py:method:: test_kind_change() .. py:class:: TestDeleteSelectedSubmissions(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_delete_one_submission() .. py:method:: test_delete_many_submissions() .. py:class:: TestSubmitSelectOneProblem(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'] .. py:method:: test_problems_list() .. py:class:: TestSubmitSelectManyProblems(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_extra_problem', 'test_contest', 'test_full_package', 'test_problem_instance'] .. py:method:: test_problems_list() .. py:class:: TestDateRegistry(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_contest'] .. py:method:: test_registry_content() .. py:class:: ContestWithPublicResultsController(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:: separate_public_results() Determines if there should be two separate dates for personal results (when participants can see their scores for a given round) and public results (when round ranking is published). Depending on the value returned, contest admins can see and modify both ``Results date`` and ``Public results date`` or only the first one. :rtype: bool .. py:class:: TestPublicResults(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'] .. py:method:: _change_controller(public_results=False) .. py:method:: test_round_inline() .. py:method:: _check_public_results(expected) .. py:method:: test_public_results_visible() .. py:method:: test_all_results_visible() .. py:class:: TestContestLinks(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'] .. py:method:: test_menu() .. py:class:: TestPersonalDataUser(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_contest', 'test_permissions'] .. py:method:: testUser() .. py:class:: TestUserInfo(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_user_info_page() .. py:class:: TestProblemInstanceView(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_permissions',... .. py:method:: test_admin_change_view() .. py:method:: separate_main_problem_instance() .. py:method:: test_resetting_limits() .. py:method:: test_rejudge_not_needed() .. py:class:: TestReattachingProblems(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_extra_contests', 'test_full_package',... .. py:method:: test_reattaching_problem() .. py:method:: test_permissions() .. py:class:: TestModifyContest(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'] .. py:method:: test_modify_contest() .. py:class:: TestRegistrationController(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_two_empty_contests', 'test_users'] .. py:method:: test_filter_visible_contests() .. py:class:: TestAdministeredContests(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_two_empty_contests', 'test_users'] .. py:method:: test_administered_contests() .. py:class:: TestSubmissionViewWithoutContest(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_contest', 'test_users', 'test_full_package', 'test_problem_site',... .. py:method:: setUp() Hook method for setting up the test fixture before exercising it. .. py:method:: test_submission_view_without_contest() .. py:class:: TestSubmissionAdminWithoutContest(methodName='runTest') Bases: :py:obj:`oioioi.base.tests.TestCase`, :py:obj:`oioioi.programs.tests.SubmitFileMixin` 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_extra_contests', 'test_users', 'test_full_package', 'test_extra_problem_instance',... .. py:method:: setUp() Hook method for setting up the test fixture before exercising it. .. py:method:: test_submission_admin_without_contest() .. py:function:: see_limits_on_problems_list(self, username, displays_submissions_limit, displays_tries_left, additional=[]) .. py:class:: TestSubmissionsLimitOnListView(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_anonymous_user() .. py:method:: test_user() .. py:method:: test_admin() .. py:function:: see_link_for_submission_on_problem_list(self, username, should_see) .. py:class:: TestSubmissionsLinksOnListView(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_link_to_submission_no_user() .. py:method:: test_link_to_submission_user() .. py:method:: test_link_to_submission_admin() .. py:class:: TestNoSubmissionsLimitOnListView(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_submission',... .. py:method:: test_not_displaying_limits() .. py:class:: TestAPIGetProblemId(methodName='runTest') Bases: :py:obj:`rest_framework.test.APITestCase` 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'] .. py:attribute:: view_name :annotation: = api_contest_get_problem_id .. py:method:: setUp() Hook method for setting up the test fixture before exercising it. .. py:method:: test_successful_query() .. py:method:: test_invalid_contest_id() .. py:method:: test_invalid_problem_short_name() .. py:class:: TestAPISubmitBase(*args, **kwargs) Bases: :py:obj:`rest_framework.test.APITestCase` 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_submission'] .. py:attribute:: extra_fixtures :annotation: = [] .. py:method:: setUp() Hook method for setting up the test fixture before exercising it. .. py:method:: submit_file(url_name, url_kwargs, file_size=1024, file_name='submission.cpp', kind=None) .. py:method:: _assertSubmitted(response, i=None) .. py:class:: TestAPIContestSubmit(*args, **kwargs) Bases: :py:obj:`TestAPISubmitBase` 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:: extra_fixtures :annotation: = ['test_problem_instance'] .. py:method:: contest_submit(contest, pi, *args, **kwargs) .. py:method:: test_simple_submission() .. py:method:: test_submissions_limitation() .. py:method:: test_huge_submission() .. py:method:: test_size_limit_accuracy() .. py:method:: _assertUnsupportedExtension(contest, problem_instance, name, ext) .. py:method:: test_limiting_extensions() .. py:class:: TestAPIProblemsetSubmit(*args, **kwargs) Bases: :py:obj:`TestAPISubmitBase` 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:: extra_fixtures :annotation: = ['test_problem_site', 'test_problem_instance_with_no_contest'] .. py:method:: problemset_submit(problem=None, site_key=None, *args, **kwargs) .. py:method:: test_problemset_submission() .. py:class:: TestManyRoundsNoEnd(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_not_sorting() .. py:function:: check_ranking_visibility(self, url, rvc) .. py:class:: TestRankingVisibility(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_user() .. py:method:: test_admin() .. py:class:: TestContestChangeForm(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'] .. py:method:: test_contest_change_form() .. py:function:: set_registration_availability(rvc, enabled, available_from=None, available_to=None) .. py:function:: check_registration(self, expected_status_code, availability, available_from=None, available_to=None) .. py:class:: TestOpenRegistration(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'] .. py:method:: test_open_registration() .. py:method:: test_closed_registration() .. py:method:: test_configured_registration_opened() .. py:method:: test_configured_registration_closed_before() .. py:method:: test_configured_registration_closed_after()