Hello,
I find the flat structure in tests/ quite convenient, especially for making
large changes, also in combination with shell globbing. Merging modeltests and
regressiontests was a win.
I'm not convinced a contrib folder would help much. Reserving foo_* for contrib
app foo sounds sufficient
I don't have a strong opinion on a nested structure for the tests; I merely
followed the existing convention for contrib tests that were already in
tests/. Note that if we do nest, we still need the "_tests" suffix (or some
distinction so to prevent duplicate app_labels from the contrib apps
th
On Monday 09 February 2015 17:38:27 Markus Holtermann wrote:
> I'm +1 on moving the contrib tests to tests/_tests/ .
>
I'm +1 on preventing tests from being packaged with the contrib apps;
I'm also +1 on moving them out of the app folders in the source -- +0 for the
move's inherent value, but +1
PR is ready for review: https://github.com/django/django/pull/4106
On Tuesday, February 10, 2015 at 12:00:13 PM UTC-5, Carl Meyer wrote:
>
> On 02/10/2015 12:08 AM, Jannis Leidel wrote:
> >> On 10 Feb 2015, at 00:12, Tim Graham >
> wrote:
> >>
> >> Is it a best practice? In my unscientific sam
On 02/10/2015 12:08 AM, Jannis Leidel wrote:
>> On 10 Feb 2015, at 00:12, Tim Graham wrote:
>>
>> Is it a best practice? In my unscientific sampling, none of the
>> following ship tests inside the application directory, but rather
>> in a separate "tests" directory. Or did I misunderstand what yo
The trickiest tests to move will be the gis tests.
When gis is enabled, django/contrib/gis/tests is added to the discovery
path. This doesn't affect which tests are discovered per se--all gis tests
are discovered anyway by discovery on the parent app
django.contrib.gis--but it causes the later
> On 10 Feb 2015, at 00:12, Tim Graham wrote:
>
> Is it a best practice? In my unscientific sampling, none of the following
> ship tests inside the application directory, but rather in a separate "tests"
> directory. Or did I misunderstand what you meant?
>
> - Django REST framework
> - djang
That'll teach me to respond to email before coffee :)
--
C
On 10 February 2015 at 10:12, Tim Graham wrote:
> Is it a best practice? In my unscientific sampling, none of the following
> ship tests inside the application directory, but rather in a separate
> "tests" directory. Or did I misunders
Is it a best practice? In my unscientific sampling, none of the following
ship tests inside the application directory, but rather in a separate
"tests" directory. Or did I misunderstand what you meant?
- Django REST framework
- django-nap
- the apps that split out from contrib (formtools, commen
Just to shine a light on another perspective- I frequently tell people to
look at contrib for "best practices", and including tests within a 3rd
party app would fall under that.
--
Curtis
On 10 Feb 2015 03:34, "Marc Tamlyn" wrote:
> +1 to removing tests from contrib itself, so long as they remai
+1 to removing tests from contrib itself, so long as they remain obviously
separated in the test section in case of future removals from core.
On 9 February 2015 at 15:44, Preston Timmons
wrote:
> I think the "need" is mainly conceptual--whether tests are more
> appropriately grouped with their
I think the "need" is mainly conceptual--whether tests are more
appropriately grouped with their app or with the other tests. With the
discover runner it's uncommon that contrib tests are included in any local
test runs.
I do prefer moving all tests into the tests directory. The logic to get
t
I'm +1 on moving the contrib tests to tests/_tests/ .
The respective ticket on Trac is https://code.djangoproject.com/ticket/24293
/Markus
On Monday, February 9, 2015 at 4:09:47 PM UTC+1, Tim Graham wrote:
>
> I wonder if there is any need to continue to ship tests as part of contrib
> apps? Cu
I wonder if there is any need to continue to ship tests as part of contrib
apps? Currently the contributing docs say, "Tests for contrib apps go in
their respective directories under django/contrib, in a tests.py file. You
can split the tests over multiple modules by using a tests directory in t
14 matches
Mail list logo
