On 7/17/06, Jyrki Pulliainen <[EMAIL PROTECTED]> wrote:
Anyway, Twill's been an ideal tool for web testing, because you cangive follow links, fill forms etc.Much like the unittest vs py.test vs nose discussion earlier, I think we should be avoiding discussions about what to bless as the 'official
On 7/13/06, Malcolm Tredinnick <
[EMAIL PROTECTED]> wrote:I know Malcolm said he was going to step away from this discussion, so this is mostly for the benefit of everyone else.
Initially, I think it will be hard to have the views entirely divorcedfrom the model framework. To do that (separate the
On 7/17/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
>
> On 7/13/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> >
> > The best way of running tests against a Django application, to my
> > mind, is to run a "fake" web server (i.e. one that doesn't actually
> > bind to a port) around the ap
Hi,
Am 17.07.2006 um 06:26 schrieb Russell Keith-Magee:
> On 7/13/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> > The best way of running tests against a Django application, to my
> > mind, is to run a "fake" web server (i.e. one that doesn't actually
> > bind to a port) around the application
On 7/13/06, Simon Willison <[EMAIL PROTECTED]> wrote:
The best way of running tests against a Django application, to mymind, is to run a "fake" web server (i.e. one that doesn't actuallybind to a port) around the application.Agreed; although I'm not sure that you actually need to run a server in th
> I completely agree -- having a testing framework that depends on an
> external package being installed is almost as bad as not having one
> at all.
>
> Batteries included, and all that...
Very true. I like the approach that Russell has taken in the patches
attached to the ticket. Having a confi
On 7/14/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
Now, what's the license of nose? Perhaps we could bundle it withDjango (as we've done with PyDispatcher and Simplejson)? In my(limited) messing with Django & nose I've been pretty happy so far(but I've not played with Russell's patch for com
On Jul 14, 2006, at 12:13 AM, Russell Keith-Magee wrote:
> On 7/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>
>>
>>> It makes coverage reports? And they work with Django? Whow!
>>
>> Sure.
>
>
> Now - that's what I call a convincing reason to switch.
Indeed :)
> I'm still hesitant to
On 7/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> It makes coverage reports? And they work with Django? Whow!Sure.
Now - that's what I call a convincing reason to switch.I'm still hesitant to make the _default_ testing scheme dependent on an external package, simply because Django doesn't
On 7/13/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
Yes, please post the patch before committing -- this is definitely a big thing.Ok; i've just attached a first pass set of patches to ticket #2333. The objectives of these patches:- Add a 'test' target to django-admin that will start the test su
> It makes coverage reports? And they work with Django? Whow!
Sure.
It uses Ned Batchelder's coverage module:
http://www.nedbatchelder.com/code/modules/coverage.html
Grab that, nose and the nose-django plugin, install the plugin with
python setup.py develop (may need sudo, depending on your pla
[EMAIL PROTECTED] wrote:
>
> To me, possibly due to my own moral failings :), the most compelling
> case is the one that speaks to developer laziness. With the nose-django
> plugin, nose does right now everything in your proposal, with the
> exception of finding non-doctests in models.py. In addi
> Unless you can make a particularly convincing case for using an alternative,
> based upon some deficiency of unittest that will adversely affect django
> testing, I'm inclined to stick with whats in the standard library.
To me, possibly due to my own moral failings :), the most compelling
case
OK, here's a brief summary of what I was thinking about. It dovetails
nicely with Simon's thinking, so I don't have to rewrite all my notes.
This is a brain dump and can probably be safely ignored if it sounds
like rubbish, for reasons I mention at the end.
On Thu, 2006-07-13 at 01:41 -0700, Simo
Michael Radziej wrote:
> Gábor Farkas wrote:
>> regarding running a "fake" webserver.. did you look at twill?
>
> But it does not allow to test against the context!
>
yes, that's why i said 'regarding running a "fake" webserver' :-)
but it offers the advantage of being able to simulate the web
Gábor Farkas wrote:
> regarding running a "fake" webserver.. did you look at twill?
But it does not allow to test against the context!
Michael
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" gr
Hey Simon,
Simon Willison wrote:
> The best way of running tests against a Django application, to my
> mind, is to run a "fake" web server (i.e. one that doesn't actually
> bind to a port) around the application. This fake server acts as a
> test harness. Tests can then create HttpRequest o
Simon Willison wrote:
>
> On 12 Jul 2006, at 02:28, Malcolm Tredinnick wrote:
>
>> I approached things from a different direction, though, more
>> concentrating on how to unit test templates and views (as in not
>> requiring a full end-to-end application setup in order to test
>> them). So
>>
On 12 Jul 2006, at 02:28, Malcolm Tredinnick wrote:
> I approached things from a different direction, though, more
> concentrating on how to unit test templates and views (as in not
> requiring a full end-to-end application setup in order to test
> them). So
> it's actually a orthogonal to wha
On 7/12/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> I'm almost ready to submit some patches (I still need to do some code
> cleanup and write some documentation), but before I do:
> 1) Are there any comments on the approach that I have suggested?
> 2) Is this a big enough change that peop
On 7/12/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Unless you can make a particularly convincing case for using an alternative,
> based upon some deficiency of unittest that will adversely affect django
> testing, I'm inclined to stick with whats in the standard library.
>
> If the powe
On Wed, 2006-07-12 at 17:13 +0300, Jyrki Pulliainen wrote:
> On 7/12/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
[...]
> > When a test targets is executed, django-admin:
> > 1) creates a test database named 'test_' + settings.DATABASE_NAME
>
> This is created to the database server being u
On 7/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Just as an additional data point, or point of discussion or whatever,...In summary, it's
py.test without the magic, plus support for pluginsthat can be used to change test selection, running and reporting.Unless you can make a particularly c
On 7/12/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
I'll write up what I was thinking about in another mail; I started topost it in response to this, but it adds no value to your proposal.Baited breath, and all that :-)
We are going to see more and more cases of a models/ sub-directory, notj
On 7/12/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
For my own project, I put together a testing middleware for viewsand manipulators, which saves the context given to a template andallows tests that are solely context based. The middleware canalso write out test cases while you use the browser.
On 7/12/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> I've got a project at work that requires a formal test harness, so I
> thought I would kill two birds with one stone and spend some time adding a
> formal test framework for all Django applications.
>
> This came up a few weeks ago [1],
Just as an additional data point, or point of discussion or whatever,
I've been working on a plugin for my test runner (nose) that is quite
similar in operation to what you've described above. If you want to
check it out, you can get nose via easy install: easy_install nose and
the plugin here:
s
On Wed, 2006-07-12 at 15:38 +0800, Russell Keith-Magee wrote:
>
> Hi all,
>
> I've got a project at work that requires a formal test harness, so I
> thought I would kill two birds with one stone and spend some time
> adding a formal test framework for all Django applications.
Hmmm .. deja vu.
Russell Keith-Magee wrote:
> I've got a project at work that requires a formal test harness, so I thought
> I would kill two birds with one stone and spend some time adding a formal
> test framework for all Django applications.
Russell, that sounds great! It looks like everyone's reinventing
the
Hi all,
I've got a project at work that requires a formal test harness, so I thought I would kill two birds with one stone and spend some time adding a formal test framework for all Django applications.
This came up a few weeks ago [1], and although I didn't comment at the time, it struck me as a
30 matches
Mail list logo
