:orphan:

:py:mod:`oioioi.disqualification.tests`
=======================================

.. py:module:: oioioi.disqualification.tests


Module Contents
---------------

Classes
~~~~~~~

.. autoapisummary::

   oioioi.disqualification.tests.TestContestController
   oioioi.disqualification.tests.TestViewsMixin
   oioioi.disqualification.tests.TestViewsProgramSubmissions
   oioioi.disqualification.tests.TestViewsQuizSubmission



Functions
~~~~~~~~~

.. autoapisummary::

   oioioi.disqualification.tests._disqualify_contestwide



.. py:function:: _disqualify_contestwide()


.. 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_contest', 'test_users', 'test_submission', 'test_full_package', 'test_problem_instance',...

      

   .. py:method:: _get_fake_request(user, contest)


   .. py:method:: test_disqualified()


   .. py:method:: test_not_disqualified()


   .. py:method:: test_disqualified_contestwide()



.. py:class:: TestViewsMixin

   Bases: :py:obj:`object`

   .. py:method:: remove_whitespaces(response)
      :staticmethod:


   .. py:method:: _assert_disqualification_box(response_callback)
      :abstractmethod:


   .. py:method:: _assert_submission(submission_id, disqualified)


   .. py:method:: test_dashboard()


   .. py:method:: test_my_submissions()


   .. py:method:: test_user_info_page()



.. py:class:: TestViewsProgramSubmissions(methodName='runTest')

   Bases: :py:obj:`oioioi.base.tests.TestCase`, :py:obj:`TestViewsMixin`

   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_instance', 'test_submission',...

      

   .. py:method:: setUp()

      Hook method for setting up the test fixture before exercising it.


   .. py:method:: _assert_disqualification_box(response_callback)


   .. py:method:: test_ranking()


   .. py:method:: test_ranking_csv()


   .. py:method:: test_submission()



.. py:class:: TestViewsQuizSubmission(methodName='runTest')

   Bases: :py:obj:`oioioi.base.tests.TestCase`, :py:obj:`TestViewsMixin`

   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_quiz_problem', 'test_problem_instance',...

      

   .. py:method:: setUp()

      Hook method for setting up the test fixture before exercising it.


   .. py:method:: _assert_disqualification_box(response_callback)


   .. py:method:: test_submission()