Sorry for starting a new thread but I thought a proposal should begin with a new thread. (Please refer to the previous thread @ https://groups.google.com/forum/#!topic/django-developers/GO65Qndw4Hg )
I'm writing in points, for easier readability. This is a very brief summary I actually wrote down for myself. *Need for Improvement/ Current Problems* 1. Running of Test Cases is slow. 2. Selection of what tests we want to run, and what all we don’t want to run is difficult 3. We have better options available *Why Py.Test?* (http://pytest.org) 1. Widely Used 2. Better reporting 3. Distributed testing (speed up, especially on multi-core machines), Line Coverage, etc using plugins 4. Third party plugins *Why Categorisation?* 1. Easy to manage tests 2. User can specify own types suitable to him. For instance -> Phase-I, Phase-II, Regression, unit, module-1, system, integration,etc 3. User can run tests in chunks (say of 2,3 test-classes belonging to a particular category) ->Faster run, as we run tests only pertaining to currently-being-modified module. 4. Ease in specifying what tests to run *How will I go about it?* Currently SimpleTestCase is a subclass of unittest.TestCase. Two ways exist -> 1. Make our own class, which gives all functionalities of unittest.TestCase in terms of Pytest constructs 2. Modify SimpleTestCase, TransactionTestCase, TestCase to use Pytest Constructs (*Pytest anyway supports unittest TestCases, Why is this required?*Difference in the way both define their constructs, causes incompatibility in certain cases. This results in false-positives. About 200 previously passing Tests are reported as failed when using pytest-django) Redefine discovery and runner accordingly. We don’t want broken tests. Check *all* Test Cases for false positives, especially those which do not have failure test cases defined. Now add ability to categorise in SimpleTestCase -> just a list of tags, specified for each test-class. (or test function?) Add ability in discovery to run only the tests, which have the tags as required. Hence discovery can now be using paths, test-labels, pattern or tags. It can also be intersection or union of any combination of these. Test cases to be run can be defined as defaults in a config file or through the command line. I'll be glad to hear your views. Thanks. Akshay Jaggi P.S. - Another way to categorise can be using a configuration file. We can specify groups, and add all test-labels that belong to that group in this file. This way, classification won't be declarative in code, but in a separate file. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bb9c0294-8d2a-432b-b651-ed6e2795092f%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
