:orphan: :py:mod:`oioioi.participants.tests` =================================== .. py:module:: oioioi.participants.tests Module Contents --------------- Classes ~~~~~~~ .. autoapisummary:: oioioi.participants.tests.ParticipantsContestController oioioi.participants.tests.OnsiteContestController oioioi.participants.tests.TestParticipantsContestViews oioioi.participants.tests.TestParticipantsSubmit oioioi.participants.tests.TestParticipantsRegistration oioioi.participants.tests.TestOpenParticipantsRegistration oioioi.participants.tests.NoAdminParticipantsRegistrationController oioioi.participants.tests.NoAdminParticipantsContestController oioioi.participants.tests.TestOnsiteAdmin oioioi.participants.tests.TestParticipantsModelAdmin oioioi.participants.tests.TestParticipantsExclusiveContestsMiddlewareMixin oioioi.participants.tests.TestRegistrationModel oioioi.participants.tests.AnonymousRegistrationController oioioi.participants.tests.AnonymousContestController oioioi.participants.tests.TestAnonymousParticipants oioioi.participants.tests.TestParticipantsDataViews oioioi.participants.tests.TestOnsiteViews oioioi.participants.tests.TestOnsiteRegistration oioioi.participants.tests.TestUserInfo Attributes ~~~~~~~~~~ .. autoapisummary:: oioioi.participants.tests.basedir .. py:data:: basedir .. py:class:: ParticipantsContestController(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:: registration_controller() .. py:class:: OnsiteContestController(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:class:: TestParticipantsContestViews(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_participants_contest_visibility() .. py:method:: test_participants_contest_access() .. py:class:: TestParticipantsSubmit(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'] .. py:method:: test_submit_permissions() .. py:class:: TestParticipantsRegistration(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_participants_accounts_menu() .. py:method:: test_participants_registration() .. py:method:: test_participants_unregister() .. py:class:: TestOpenParticipantsRegistration(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:: setUp() Hook method for setting up the test fixture before exercising it. .. py:method:: test_participants_registration() .. py:method:: test_contest_info() .. py:class:: NoAdminParticipantsRegistrationController(contest) Bases: :py:obj:`oioioi.participants.controllers.ParticipantsController` A base class for classes which should have a list of subclasses available. The list of subclasses is available in their :attr:`subclasses` class attributes. Classes which have *explicitly* set :attr:`abstract` class attribute to ``True`` are not added to :attr:`subclasses`. If a class has ``modules_with_subclasses`` attribute (list or string), then specified modules for all installed applications can be loaded by calling :meth:`~RegisteredSubclassesBase.load_subclasses`. .. py:property:: participant_admin .. py:class:: NoAdminParticipantsContestController(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:: registration_controller() .. py:class:: TestOnsiteAdmin(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:: setUp() Hook method for setting up the test fixture before exercising it. .. py:method:: test_admin_menu() .. py:method:: test_regions_admin() .. py:method:: test_participants_import() .. py:class:: TestParticipantsModelAdmin(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_permissions'] .. py:method:: test_participants_admin_visibility() .. py:method:: test_noadmin_admin_visibility() .. py:method:: test_participants_import() .. py:class:: TestParticipantsExclusiveContestsMiddlewareMixin(methodName='runTest') Bases: :py:obj:`oioioi.base.tests.TestCase`, :py:obj:`oioioi.contestexcl.tests.ContestIdViewCheckMixin` 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:: setUp() Hook method for setting up the test fixture before exercising it. .. py:method:: test_participants_selector() .. py:method:: test_contest_admin_with_participant() .. py:class:: TestRegistrationModel(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_both_hands_cascading_on_registration_delete() .. py:class:: AnonymousRegistrationController(contest) Bases: :py:obj:`oioioi.oi.controllers.OIRegistrationController` A base class for classes which should have a list of subclasses available. The list of subclasses is available in their :attr:`subclasses` class attributes. Classes which have *explicitly* set :attr:`abstract` class attribute to ``True`` are not added to :attr:`subclasses`. If a class has ``modules_with_subclasses`` attribute (list or string), then specified modules for all installed applications can be loaded by calling :meth:`~RegisteredSubclassesBase.load_subclasses`. .. py:method:: allow_login_as_public_name() Determines if participants may choose to stay anonymous, i.e. use their logins as public names. .. py:class:: AnonymousContestController(contest) Bases: :py:obj:`oioioi.oi.controllers.OIContestController` Contains the contest logic and rules. This is the computerized implementation of the contest's official rules. .. py:method:: registration_controller() .. py:class:: TestAnonymousParticipants(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_schools', 'test_full_package', 'test_problem_instance',... .. py:method:: _register(user, anonymous=False, possible=False) .. py:method:: test_no_anonymous_participants() .. py:method:: test_anonymous_participants() .. py:method:: test_user_info_page() .. py:class:: TestParticipantsDataViews(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_schools'] .. py:method:: register(contest) .. py:method:: test_no_email_data_view() .. py:method:: test_data_view() .. py:method:: test_none_school() .. py:class:: TestOnsiteViews(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_contest_visibility() .. py:method:: test_contest_access() .. py:class:: TestOnsiteRegistration(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:: setUp() Hook method for setting up the test fixture before exercising it. .. py:method:: test_missing_registration_model() .. py:method:: test_participants_accounts_menu() .. py:method:: test_participants_unregister_forbidden() .. 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_permissions'] .. py:method:: test_onsite_user_info_page()