Re: test discovery

Hi Carl, On Sat, 18 May 2013, Carl Meyer wrote: I don't think this should be fixed in the test runner itself; in general, file-path test labels _should_ be interpreted as relative to wherever you are running the tests from. But it should be fixed in the

Re: test discovery

Hi Chris, On May 18, 2013, at 8:34 AM, Chris Wilson wrote: > On Sat, 18 May 2013, Chris Wilson wrote: > >> I think Travis is unhappy about something in this commit. Any ideas? >> >> == >> ERROR:

Re: test discovery

Hi Chris, On May 18, 2013, at 9:42 AM, Chris Wilson wrote: > Another odd behaviour of the new test runner. This runs the tests, but fails > to add the test app to INSTALLED_APPS, so they all fail because their tables > are not created: > >PYTHONPATH=.. python -Wall

Re: test discovery

Hi all, On Fri, 10 May 2013, Carl Meyer wrote: I merged this patch tonight. Thanks to everyone who contributed! Now let's see how the CI servers feel about it... I think Travis is unhappy about something in this commit. Any ideas?

Re: test discovery

Russ & Carl, I'm interested in this one, so I sketched up a potential avenue tonight (https://github.com/toastdriven/django/compare/check_setup). I actually implemented Russ' setup first, but ran into a couple issues, so I pared it down into an "opt-in" scheme. If there's a feeling like

Re: test discovery

On Saturday, May 11, 2013 2:38:23 PM UTC+2, Carl Meyer wrote: > > No good reason, just an oversight I think. If that's all that's needed to > make the CI happy, feel free to change it, should be a simple fix. > Perfect, pushed a fix, let's see what jenkins says. -- You received this message

Re: test discovery

Hi Florian, On May 11, 2013, at 7:51 AM, Florian Apolloner wrote: > Hi Carl, > > before I read all the tickets etc; why does runtests.py not use the > TEST_RUNNER from settings.py (see >

Re: test discovery

Hi Carl, before I read all the tickets etc; why does runtests.py not use the TEST_RUNNER from settings.py (see https://github.com/django/django/commit/9012833af857e081b515ce760685b157638efcef#L60L149)? We'd need that for jenkins to produce xml files as output. Thanks, Florian -- You

Re: test discovery

Not good, at least our Jenkins runner which should generate xml output doesn't like it :/ On Saturday, May 11, 2013 5:36:55 AM UTC+2, Carl Meyer wrote: > > I merged this patch tonight. Thanks to everyone who contributed! Now let's > see how the CI servers feel about it... > > Carl > > On

Re: test discovery

Wow, this is awesome! Thanks so much guys. Too long have I dreamt of the day when I could include tests for my "lib" and "util", etc. without having to couple them to one app or another. I'm so excited that this was added so quickly. Thanks Yo-yo -- You received this message because you

Re: test discovery

I merged this patch tonight. Thanks to everyone who contributed! Now let's see how the CI servers feel about it... Carl On Wednesday, May 8, 2013 5:00:56 PM UTC-4, Carl Meyer wrote: > > Preston Timmons and I have been working the last several weeks to get > the test discovery branch (#17365)

Re: test discovery

On Thursday, May 9, 2013 8:15:02 PM UTC-4, Russell Keith-Magee wrote: > On Thu, May 9, 2013 at 11:30 PM, Carl Meyer > wrote: > >> Hi Russ, >> >> On 05/09/2013 04:51 AM, Russell Keith-Magee wrote: >> > Great work Carl and Preston! (And everyone else who had a hand in the >> >

Re: test discovery

On Thu, May 9, 2013 at 11:30 PM, Carl Meyer wrote: > Hi Russ, > > On 05/09/2013 04:51 AM, Russell Keith-Magee wrote: > > Great work Carl and Preston! (And everyone else who had a hand in the > > patch - I know this has been kicking around for a while now) > > Thanks for the

Re: test discovery

On 05/09/2013 07:50 AM, Andrew Godwin wrote: > Just want to say that I'm happy with a "fast transition". > > Is there a possibility we can detect the case where the tests might be > broken (how might they be?) and print a helpful error message? Two kinds of potential breakage: - The most common

Re: test discovery

Hi Russ, On 05/09/2013 04:51 AM, Russell Keith-Magee wrote: > Great work Carl and Preston! (And everyone else who had a hand in the > patch - I know this has been kicking around for a while now) Thanks for the reminder; I should have mentioned that Mahdi Yusuf did the initial draft patch, based

Re: test discovery

Hi Tom, On 05/09/2013 03:27 AM, Tom Christie wrote: > * Will it be possible to globally configure the default file/path pattern? > Jannis's django-discover-runner includes support for a > `TEST_DISCOVER_PATTERN` - is there anything similar, or just the command > line `--patterns` option? The

Re: test discovery

Just want to say that I'm happy with a "fast transition". Is there a possibility we can detect the case where the tests might be broken (how might they be?) and print a helpful error message? Andrew On Thu, May 9, 2013 at 11:51 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > On

Re: test discovery

On Thu, May 9, 2013 at 5:00 AM, Carl Meyer wrote: > Hi all, > > Preston Timmons and I have been working the last several weeks to get > the test discovery branch (#17365) ready for merge, and I think we now > have a pull request ready for consideration: >

Re: test discovery

Hi Carl, Excellent, excellent stuff - many thanks to both yourself and Preston. Couple of questions: * Will it be possible to globally configure the default file/path pattern? Jannis's django-discover-runner includes support for a `TEST_DISCOVER_PATTERN` - is there anything similar, or

Re: test discovery

Hi Anssi, On 05/08/2013 03:31 PM, Anssi Kääriäinen wrote: > It would be really nice to be able to use same syntax for running a > single Django's testcase at least for a while. I expect that there > will be problems if inspecting how a given test case behaves in older > versions compared to HEAD.

Re: test discovery

On Wed, May 8, 2013 at 2:00 PM, Carl Meyer wrote: > Jacob has suggested that back-compat breaks in test-running are not as > serious as in production code, and that we should just switch to the new > test runner by default in Django 1.6. I still think this. I don't see the need

Re: test discovery

It would be really nice to be able to use same syntax for running a single Django's testcase at least for a while. I expect that there will be problems if inspecting how a given test case behaves in older versions compared to HEAD. Also, bisecting over the test case renaming boundary will be

Re: test discovery

On 8 mai 2013, at 23:00, Carl Meyer wrote: > Jacob has suggested that back-compat breaks in test-running are not as > serious as in production code, and that we should just switch to the new > test runner by default in Django 1.6. This is what the pull request > currently does.

Re: test discovery

On May 8, 2013, at 5:00 PM, Carl Meyer wrote: > Jacob has suggested that back-compat breaks in test-running are not as > serious as in production code, and that we should just switch to the new > test runner by default in Django 1.6. This is what the pull request > currently