:orphan: :py:mod:`oioioi.sinolpack.tests` ================================ .. py:module:: oioioi.sinolpack.tests Module Contents --------------- Classes ~~~~~~~ .. autoapisummary:: oioioi.sinolpack.tests.TestSinolPackageIdentify oioioi.sinolpack.tests.TestSinolPackage oioioi.sinolpack.tests.TestSinolPackageInContest oioioi.sinolpack.tests.TestSinolPackageCreator oioioi.sinolpack.tests.TestJudging oioioi.sinolpack.tests.TestLimits Functions ~~~~~~~~~ .. autoapisummary:: oioioi.sinolpack.tests.get_test_filename oioioi.sinolpack.tests.use_makefiles oioioi.sinolpack.tests.no_makefiles oioioi.sinolpack.tests.enable_both_unpack_configurations oioioi.sinolpack.tests.both_configurations Attributes ~~~~~~~~~~ .. autoapisummary:: oioioi.sinolpack.tests.BOTH_CONFIGURATIONS .. py:function:: get_test_filename(name) .. py:data:: BOTH_CONFIGURATIONS :annotation: = %test_both_configurations .. py:function:: use_makefiles(fn) .. py:function:: no_makefiles(fn) .. py:function:: enable_both_unpack_configurations(cls) .. py:function:: both_configurations(fn) .. py:class:: TestSinolPackageIdentify(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_identify_zip() .. py:method:: test_identify_tgz() .. py:class:: TestSinolPackage(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'] .. py:method:: test_title_in_config_yml() .. py:method:: test_single_file_replacement() .. py:method:: test_title_translations_in_config_yml() .. py:method:: test_title_from_doc() .. py:method:: test_latin2_title_from_doc() .. py:method:: test_utf8_title_from_doc() .. py:method:: test_utf8_title_from_config() .. py:method:: test_memory_limit_from_doc() .. py:method:: test_attachments() .. py:method:: test_attachments_no_directory() .. py:method:: test_attachments_empty_directory() .. py:method:: test_attachments_reupload_same_attachments() .. py:method:: test_attachments_reupload_no_attachments() .. py:method:: test_assign_points_from_file() .. py:method:: test_assign_global_time_limit_from_file() .. py:method:: test_assign_time_limits_for_groups_from_file() .. py:method:: test_assign_time_limits_for_groups_nonexistent() .. py:method:: test_assign_time_limits_for_different_levels() .. py:method:: test_assign_points_nonexistent() .. py:method:: test_assign_points_not_exhaustive() .. py:method:: test_huge_unpack_update() .. py:method:: _check_no_ingen_package(problem, doc=True) .. py:method:: test_no_ingen_package() .. py:method:: _check_full_package(problem, doc=True) .. py:method:: test_full_unpack_update() .. py:method:: _check_interactive_package(problem) .. py:method:: test_interactive_task() .. py:method:: _add_problem_with_author(filename, author, nothrow=False) .. py:method:: test_restrict_html() .. py:method:: test_overriden_limits_with_reupload() .. py:class:: TestSinolPackageInContest(methodName='runTest') Bases: :py:obj:`django.test.TransactionTestCase`, :py:obj:`oioioi.filetracker.tests.TestStreamingMixin` A class whose instances are single test cases. By default, the test code itself should be placed in a method named 'runTest'. If the fixture may be used for many test cases, create as many test methods as are needed. When instantiating such a TestCase subclass, specify in the constructor arguments the name of the test method that the instance is to execute. Test authors should subclass TestCase for their own tests. Construction and deconstruction of the test's environment ('fixture') can be implemented by overriding the 'setUp' and 'tearDown' methods respectively. If it is necessary to override the __init__ method, the base class __init__ method must always be called. It is important that subclasses should not change the signature of their __init__ method, since instances of the classes are instantiated automatically by parts of the framework in order to be run. When subclassing TestCase, you can set these attributes: * failureException: determines which exception will be raised when the instance's assertion methods fail; test methods raising this exception will be deemed to have 'failed' rather than 'errored'. * longMessage: determines whether long messages (including repr of objects used in assert methods) will be printed on failure in *addition* to any explicit message passed. * maxDiff: sets the maximum length of a diff in failure messages by assert methods using difflib. It is looked up as an instance attribute so can be configured by individual tests if required. .. py:attribute:: fixtures :annotation: = ['test_users', 'test_contest'] .. py:method:: test_upload_and_download_package() .. py:method:: test_inwer_failure_package() .. py:class:: TestSinolPackageCreator(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_full_package', 'test_problem_instance_with_no_contest'] .. py:method:: test_sinol_package_creator() .. py:class:: TestJudging(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_judging() .. py:class:: TestLimits(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:: upload_package() .. py:method:: test_time_limit() .. py:method:: test_memory_limit()