7;t too long ago that this proposal would
have been "switch the Django test runner to nose", and now nose is
unmaintained and deprecated (its last release was in 2015) and though
there's a maintained "nose2" fork, it's not compatible with the
original and doesn't ha
..@gmail.com wrote:
>>>
>>>> A case could be made along the same lines as was made for South.
>>>>
>>>> Get Outlook for Android <https://aka.ms/ghei36>
>>>>
>>>> --
>>>> *From:* django-d...@go
;
>>> A case could be made along the same lines as was made for South.
>>>
>>> Get Outlook for Android <https://aka.ms/ghei36>
>>>
>>> --
>>> *From:* django-d...@googlegroups.com on
>>> behalf of Mariusz Feli
South.
>>
>> Get Outlook for Android <https://aka.ms/ghei36>
>>
>> --
>> *From:* django-d...@googlegroups.com on
>> behalf of Mariusz Felisiak
>> *Sent:* Tuesday, December 15, 2020 9:58:56 PM
>> *To:* Django developers (Co
8:56 PM
> *To:* Django developers (Contributions to Django itself) <
> django-d...@googlegroups.com>
> *Subject:* Re: Replace the default django test runner to a more robust
> testing framework (like pytest)
>
> Hi,
>
> I agree with René and Adam, pytest and pytest-dj
> I agree with René and Adam, pytest and pytest-django already exist, and I
don't see why we should copy it to Django or change the default test runner.
I am not talking about replicating any code-base whatsoever. What I am
proposing instead is official django support for pytest. Kind of like how
lopers (Contributions to Django itself)
Subject: Re: Replace the default django test runner to a more robust testing
framework (like pytest)
Hi,
I agree with René and Adam, pytest and pytest-django already exist, and I
don't see why we should copy it to Django or change the default test ru
Hi,
I agree with René and Adam, pytest and pytest-django already exist, and
I don't see why we should copy it to Django or change the default test
runner.
Best,
Mariusz
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Djan
*Ahmad*, thanks for your views! Here's what I think.
> I personally believe it should be in core because a lot of custom
features we'd like to add to the test runner already exist in pytest's rich
ecosystem. Just as Tom mentioned, adding timings was a lot harder than
expected while such a featu
Hi
Whilst I appreciate the effort and love pytest, I don't think this it's
feasible at the moment to even suggest to users that they use pytest, let
alone make it a default or port Django's unittest-based framework.
For a first step, we have our backwards compatibility policy. Any move away
from
Thank you everyone for your inputs! I don't know how you all are using the
quote feature, so I will address you all by your names.
- *Jacob*: Thank you for your support! The ticket you linked to is very
helpful. It is upside of 5 years old. *pytest *has evolved a lot over
that time, a
Hi Diptesh,
This is a great idea! (And one that has had a fair bit of discussion). I
don't think anyone holds an opinion against supporting pytest as a testing
tool, but I believe the main hurdle is laying a convincing argument why
this support should be in Django Core versus remaining in its curr
Hi,
On 15.12.20 15:48, Tobias Bengfort wrote:
My issue is mostly that pytest uses a lot of magic that is hard to
debug, e.g. the overwritten assert statement or implicit injection of
fixtures. Most pro arguments seem to depend on personal taste.
It should be noted that you can use pytest / py
I would be very much in favour of this. The developer experience of pytest is
far better than the unittest module, the tests look more Pythonic and there is
a lot more of an ecosystem we can tap into.
There was some recent work done about adding timings to the Djanfo test suite
as part of the m
Hi Diptesh,
I think it is great that you want to work on this. I also think asking
for feedback now is the right way to go.
That said, I personall have not had the best experience with pytest. I
have mostly worked on smaller projects though, so my perspective might
be very limited.
My issu
There is already a ticket for this:
https://code.djangoproject.com/ticket/25707
I'm actually very much in favor of switching to pytest. In my newer
projects I use pytest exclusively.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions
Though the django default runner gets the job done, I think its high time
to leverage the power of dedicated frameworks for testing django apps. I
will take up the case of *pytest* here because other frameworks like *nose *
are not widely used.
For everyone who has used pytest for testing in dja
On Sep 14, 4:16 pm, Carl Meyer wrote:
>
> I'm generally in favor of updating Django's test runner to be more
> consistent with what the rest of the Python testing world does. Being
> able to reference test files, suites, and tests by
> fully-qualified-dotted-path rather than magical-applabel-path
Like Carl and Travis said, Django's test runner supports the notion that a
Django app has all it's test cases collected in the `models` and `tests`
module.
Most of the time, If your app's `tests` module gets too crowded, fracturing
the app into smaller apps works. However, if you have to go for
Hello;
I second all of what Carl said and would like to point out the app-refactor.
I believe the most current code still lives in the app-loading branch on
jezdez's repository on GitHub[1]. The reason I point this out is because
the current testing structure is a legacy of the way Django intern
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/13/2011 08:46 AM, mvr wrote:
> Why doesn't the django test management command / test builder allow
> fully-qualified package names instead of just app-relative ones?
>
> At work we've been using the method below to monkey-patch the test
> builde
Why doesn't the django test management command / test builder allow
fully-qualified package names instead of just app-relative ones?
At work we've been using the method below to monkey-patch the test
builder, so that
$ django-admin.py test my_module.my_app.tests.some_test_file
always works as e
On Thu, May 28, 2009 at 12:44 PM, Alex Robbins
wrote:
>
> It would be really great if the test runner had an excludes option. I
> would like to run tests from all apps, except for a couple I know are
> bad. Should I just make my own custom test runner or is this something
> others would like also
It would be really great if the test runner had an excludes option. I
would like to run tests from all apps, except for a couple I know are
bad. Should I just make my own custom test runner or is this something
others would like also?
Alex
--~--~-~--~~~---~--~~
You
24 matches
Mail list logo
