#32178: Allow database backends to skip tests and mark expected failures
-------------------------------------+-------------------------------------
               Reporter:  Tim        |          Owner:  nobody
  Graham                             |
                   Type:  New        |         Status:  new
  feature                            |
              Component:  Database   |        Version:  master
  layer (models, ORM)                |
               Severity:  Normal     |       Keywords:
           Triage Stage:             |      Has patch:  0
  Unreviewed                         |
    Needs documentation:  0          |    Needs tests:  0
Patch needs improvement:  0          |  Easy pickings:  0
                  UI/UX:  0          |
-------------------------------------+-------------------------------------
 Currently Django's built-in database backends have special privileges in
 the test suite when it comes to test skipping such as:
 `tests/model_fields/test_integerfield.py:
 @unittest.skipIf(connection.vendor == 'sqlite', "SQLite doesn't have a
 constraint.")`

 While `DatabaseFeatures` attributes are generally preferred to
 `connection.vendor` checking, I think allowing backends to skip certain
 tests has its place. Adding features flags that are likely to apply to
 only a single database is a bit cumbersome, especially for third-party
 backends.

 Django should provide more generic way to skip tests and mark expected
 failures. For example, see [https://github.com/cockroachdb/django-
 
cockroachdb/blob/6304e41fc5725fcfe53b851498529c339ba89f20/django_cockroachdb/creation.py#L17-L214
 django-cockroachdb's logic] which was inspired by
 [https://bitbucket.org/Manfre/django-
 mssql/src/master/sqlserver_ado/creation.py django-mssql-backend]. In a
 more refined version, `expected_failures` and `skip_classes` would be
 attributes of `DatabaseFeatures`.

 That logic uses a `RUNNING_COCKROACH_BACKEND_TESTS` environment variable
 to decide whether or not the Django test suite is running. There might be
 a better way to determine that. At least the variable name would be more
 generic.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/32178>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.9fbea9a4d09d2591c8492680e7392a25%40djangoproject.com.

Reply via email to