Hi Akshay, On Fri, Feb 14, 2014 at 9:12 PM, Akshay Jaggi <[email protected]>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 [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/CAJxq84-ZFoS4xTp42Xv5QDX1m6Vyq%2BvAzm_XSRuGVty7h38itQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
