Hi Akshay, On Fri, Feb 14, 2014 at 9:12 PM, Akshay Jaggi <akshay1994....@gmail.com>wrote:
> Hello! > I was planning to work on improving the Test-Suite for GSOC 2014. > I would need some help in formalising and improving my proposal, so that > it meets the requirements. > Great to hear! Here's some feedback: > One of the improvements I see is classification of test cases. Classifying > them into categories (read multiple-categories), would make it easier for > users/developers/maintainers to run them. Basis of classification,etc is > what I am still thinking on. But surely classification will help in > deciding which all test cases to run. For example - just running > third-party app test cases, or just run my test cases, or those which check > part ABC of my project, or just those with priority set to important. > > How to run tests? Here we have a few choices. > -> Allowing the ability to decide and run test cases from the admin > interface. (Will people like it? Choosing what tests to run will become > easy for sure. This will require the server to be up though. Will this be > problematic?) > This doesn't sound like a very viable idea to me. This is something that needs to be persisted in code; a web server interface to manage this doesn't strike me as a good idea. Unless you've got a particularly inspired way for handling this, I don't think this will work. > -> Sticking with and improving the current way. Specify what all tests to > be run. (Do I want to add to this, every time I put new apps/add test > cases? Or delete from this?) > Specify default settings per app? App developer can decide if he wants the > tests to be included or excluded by default. Helpful, if say, app (or > certain components of the app) not dependent on other things, say DB,etc. > and it has been tested many times before, then there is no need to run > those tests by default. > -> Having both of the above. ( Coherence between both of these? ) > I would envisage that this would be a declarative process - in code, marking a specific test as a "system" test or an "integration" test (or whatever other categories we develop). > I'm still brain-storming on other possible improvements we can do. And I > am going through tickets to see current problems with testing. > > I'm willing to hear your opinions and comments. > My other comment: have a look into how other systems handle this. In particular, look at other test running tools, like nose and py.test. Where at all possible, I would prefer to avoid reinventing the wheel; if we can leverage the tools of an existing testing framework, then we should do that in preference to building our own. Yours, Russ Magee %-) -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/CAJxq84-ZFoS4xTp42Xv5QDX1m6Vyq%2BvAzm_XSRuGVty7h38itQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
