Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Another advantage of Pytest is its ability to launch tests written in all styles - PyUnit, Nose, and Pytest own style. Recently I understood that it is a good practice to launch tests not only for project, but for all packages it uses before deployment - to ensure that nothing is broken (like mi

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Hi Chris, Just a couple notes to set the record straight: On Sunday, April 6, 2014 1:02:18 PM UTC-4, Chris Wilson wrote: > > Hi Andrew, > > I'm not a Django core contributor but just a user and occasional patcher. > I submit some comments on this proposal in the hope that they will be > useful

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Before this thread goes too far, I'd like to express my doubts regarding the goals you stated. 2014-02-27 20:50 GMT+01:00 Akshay Jaggi : > > *Need for Improvement/ Current Problems* > >1. Running of Test Cases is slow. > > I don't know what the threshold for "slow" is, but faster is obviously

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Hi Chris, It looks like you invoke nosetests and not py.test, therefore you do not get the results one would expect with py.test: On 7 apr 2014, at 11:52, Chris Wilson wrote: > OK, here is one. > > chris@lap-x201:~/projects/2014/webassets$ .ve/bin/tox -e py27 -- > tests.test_filters:TestPyScs

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Hi Andrew, On Sun, 6 Apr 2014, Chris Wilson wrote: On Sun, 6 Apr 2014, Andrew Pashkin wrote: * It makes it much harder to write custom assertions and get meaningful display on error. Can you give an examples for cases with messages/breakings and for custom assertions? I don't have an exam

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Hi Andrew, On Sun, 6 Apr 2014, Andrew Pashkin wrote: * It makes it much harder to write custom assertions and get meaningful display on error. Can you give an examples for cases with messages/breakings and for custom assertions? I don't have an example of breakage to hand, I ripped out the

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

...Sometimes it gets different results (if one of the tested methods has side effects) and then the assertion message makes no sense, hides the problem, or pytest breaks. * It makes it much harder to write custom assertions and get meaningful display on error. Can you give an examples for ca

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

On 6 April 2014 17:24, Andrew Pashkin wrote: > Some Pytest advocacy: > 1) Pytest has convenient tests collection options - you can just specify > folder to run all tests in it. It is also possible to filter tests by regex, > and select specific ones. Sounds good, but unittest's test discovery is

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Hi Andrew, I'm not a Django core contributor but just a user and occasional patcher. I submit some comments on this proposal in the hope that they will be useful. On Sun, 6 Apr 2014, Andrew Pashkin wrote: Some Pytest advocacy: 1) Pytest has convenient tests collection options - you can just

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Some Pytest advocacy: 1) Pytest has convenient tests collection options - you can just specify folder to run all tests in it. It is also possible to filter tests by regex, and select specific ones. 2) PyUnit: class MyTestCase(TestCase): def test_something(self): expected_content = ..

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

On Fri, Feb 28, 2014 at 4:17 AM, Gwildor Sok wrote: > Personally I'm a big fan of Py.test, simply because it's so simple and > Pythonic to use. Simple functions with simple assert statements. That's > all. For me this significantly lowers the threshold to write tests and > requires less effort, w

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Personally I'm a big fan of Py.test, simply because it's so simple and Pythonic to use. Simple functions with simple assert statements. That's all. For me this significantly lowers the threshold to write tests and requires less effort, which in the end results in way more tests written in Py.te

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

> > >>1. Distributed testing (speed up, especially on multi-core machines), >>Line Coverage, etc using plugins >> >> How would this work? We still have shared resources like the database > where you can't just run 10 Test against in parallel. > There is django plugin for py.test

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Hi Akshay, On Thursday, February 27, 2014 8:50:32 PM UTC+1, Akshay Jaggi wrote: > > *Why Py.Test?* (http://pytest.org) > >1. Widely Used > > So is nose and unittest, you'll need to add a bit more info to such statements. > >1. Better reporting > > Better how exactly? > >1. Distrib

[GSOC] Shifting to Py.Test and Improving the Test Suite

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 d