Support reset sequences

[sliverc]

Picking up work done in #308

This adds support for using the reset_sequences feature of Django's TransactionTestCase.

It will try to reset all automatic increment values before test execution, if the database supports it. This is useful when you have tests that rely on such values, like ids or other primary keys such as snapshot testing of apis with snapshottest.

[codecov-io]

Codecov Report

Merging #619 into master will increase coverage by 0.18%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #619      +/-   ##
==========================================
+ Coverage   92.36%   92.54%   +0.18%     
==========================================
  Files          32       32              
  Lines        1715     1757      +42     
  Branches      142      149       +7     
==========================================
+ Hits         1584     1626      +42     
  Misses         94       94              
  Partials       37       37

Flag	Coverage Δ
#dj110	84.63% <93.1%> (+0.14%)	⬆️
#dj111	86.9% <100%> (+0.32%)	⬆️
#dj18	85.42% <93.1%> (+0.12%)	⬆️
#dj19	84.4% <89.65%> (+0.03%)	⬆️
#dj20	84.91% <93.1%> (+0.13%)	⬆️
#dj21	84.91% <93.1%> (+0.13%)	⬆️
#mysql_innodb	84.91% <93.1%> (+0.13%)	⬆️
#mysql_myisam	84.74% <89.65%> (+0.02%)	⬆️
#postgres	88.21% <93.1%> (+0.05%)	⬆️
#py27	89.98% <100%> (+0.24%)	⬆️
#py34	84.4% <89.65%> (+0.03%)	⬆️
#py35	84.63% <93.1%> (+0.14%)	⬆️
#py36	85.48% <96.55%> (+0.23%)	⬆️
#sqlite	86.56% <89.65%> (-0.03%)	⬇️
#sqlite_file	84.4% <89.65%> (+0.03%)	⬆️

Impacted Files	Coverage Δ
tests/test_database.py	99.16% <100%> (+0.26%)	⬆️
pytest_django/plugin.py	86.12% <100%> (+0.12%)	⬆️
pytest_django/fixtures.py	97.09% <100%> (+0.17%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0e7fc3b...04f117b. Read the comment docs.

[blueyed]

Thanks. I assume this would also close #353 then?

Reminded me also of #431 - what do you think?

[blueyed]

Would be nice to get the diff covered 100%: https://codecov.io/gh/pytest-dev/pytest-django/compare/db44ccfdcc2fb710a731ca32efb6929824b50c44...db260270b074e8692cbfe51c0825d88b7b319dcf/diff

[blueyed]

btw: thanks for improving the docs - I think it would make sense to only have it in one place though, and then use Sphinx' automethod directive etc.

[sliverc]

• This PR only introduces setting of reset_sequences flag - to fix Add support for serialized rollback #353 also serialized_rollback would need to be set. Expose fixtures to change Django's {Transaction,}TestCase #431 is a whole different approach. Not sure though whether exposing testcase is really pytesty though...
• Added more tests to fix the coverage issue.
• In terms of documentation. I agree automethod would properly be a good idea. Currently this hasn't been used anywhere in the documentation, so potentially it needs some restructuring. I have a feeling this is out of scope for this PR but maybe you can give a example what you would use automethod for in the scope of this PR?

[blueyed]

Thanks for your summary!

#431 is a whole different approach. Not sure though whether exposing testcase is really pytesty though...

I feel like it would add the most flexibility, and could be a good base for reset_sequences (and serialized_rollback later). I've not looked into it deeply though.

Re docs:

• sphinx.ext.autodoc needs to be added in docs/conf.py to extendsions

• I've looked into this when noticing that the live_server documentation is duplicated in docs/helpers.rst and the docstring, there this would be used:

  .. fixture:: live_server
  .. autofunction:: pytest_django.fixtures.live_server

I agree that it might be out of scope, but wanted to mention it since you are documenting the fixture in two places, but a single one would suffice: https://github.com/pytest-dev/pytest-django/pull/619/files#diff-352a76c86a6f0e0377970c01375e1e39R231 and https://github.com/pytest-dev/pytest-django/pull/619/files#diff-b8d58f3cc3175f8ec7bc9441f7d0bd32R191.

[blueyed]

You can use intersphinx here:

diff --git i/docs/helpers.rst w/docs/helpers.rst
index 78e62ee..e2cfede 100644
--- i/docs/helpers.rst
+++ w/docs/helpers.rst
@@ -45,7 +45,7 @@ test will fail when trying to access the database.
  values (e.g. primary keys) before running the test.  Defaults to
  ``False``.  Must be used together with ``transaction=True`` to have an
  effect.  Please be aware that not all databases support this feature.
- For details see `django.test.TransactionTestCase.reset_sequences`_
+ For details see :py:attr:`django.test.TransactionTestCase.reset_sequences`.
 
 .. note::
 
@@ -63,7 +63,6 @@ test will fail when trying to access the database.
  Test classes that subclass Python's ``unittest.TestCase`` need to have the
  marker applied in order to access the database.
 
-.. _django.test.TransactionTestCase.reset_sequences: https://docs.djangoproject.com/en/dev/topics/testing/advanced/#django.test.TransactionTestCase.reset_sequences
 .. _django.test.TestCase: https://docs.djangoproject.com/en/dev/topics/testing/overview/#testcase
 .. _django.test.TransactionTestCase: https://docs.djangoproject.com/en/dev/topics/testing/overview/#transactiontestcase

You can use python -msphinx.ext.intersphinx https://docs.djangoproject.com/en/dev/_objects/ | less to see the available targets.

[sliverc]

Nice! Adjusted it likewise.

[sliverc]

• I have played around a bit with autodoc. It seems that it includes the signature of the function as well and I couldn't find a way not too. If I would just use autofunction for django_db_reset_sequences it would look different to the other fixtures documented. And seeing the signature is also quite confusing as not important to user.
  Maybe you know a way how to hide it? Otherwise not sure whether introducing autofunction just for this PR makes sense.
• concerning approach in Expose fixtures to change Django's {Transaction,}TestCase #431 I totally see that this is more flexible than creating a single fixture for each feature. It kind of feels wrong though to expose unit test cases in pytest, but maybe thats just me 😉 The example done in the PR is to support multi_db support. I am not fully aware what is really needed for this to work but kind of have a feeling just the flag multi_db properly won't add full multi db support as changes will also be done how databases are created (I might be wrong...)
  This said I would prefer if pytest-django only simply exposes the features it supports with fixtures instead of exposing test cases where some features might not work which can be changed.

What do you think concerning this PR - would you like to change the approach how it is done or do you see it in a merging state whereas issues in #431 and #353 can be solved in a different context?

[blueyed]

I think this PR is fine for now!
As for #431 it could only be used internally also, of course and/or creating wrapper fixtures based on it.
But that could be done later still.

[cb109]

@sliverc I am happy you have picked this up, thanks and cheers 🤗

[blueyed]

Rebased, planning to add it to the next release / merge it soon.