View Issue Details

IDProjectCategoryView StatusLast Update
0005023Talerobsolete componentpublic2018-04-15 18:34
ReporterMarcello Stanisci Assigned ToMarcello Stanisci Resolution deadline
ImplementerReviewer 
Release signed byDeployed by 
VerifierCommunicator 
Data protection authority notification requiredNo  
CSIRT notification requiredNo  
Estimated effort (hours)Actual effort (hours)0 
Fast-trackNo
Work packagenone
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionno change required 
Product Versiongit (master) 
Target Version0.5Fixed in Version0.5 
Summary0005023: Avoid django's TestCase class
DescriptionBank's testcases should import python's unittest module and run test against
it, rather than import django's TestCase class. This way it's easier to catch
errors before tests are run.

For example, errors like django.db.utils.OperationalError are uncatchable by django's
TestCase class. If instead we bypass all the django initialization logic and use python's
unittest directly, we will have more freedom to check if the environment is OK and return
accordingly.
TagsNo tags attached.

Required notifications

Address or linkRemarkAdded byNotifiedActions

Activities

Marcello Stanisci

2017-05-23 19:44

reporter   ~0012150

WARNING: this way we lose the (HTTP) Client class exported by django.

Florian Dold

2017-05-23 19:51

manager   ~0012151

In what sense? Why can't we still use the HTTP class?

Florian Dold

2017-05-23 19:55

manager   ~0012152

FYI, you can see the implementation of the Django TestCase here: https://github.com/django/django/blob/538bf43458a147b7edeb7118c9f325c3f59ff6fb/django/test/testcases.py#L953

If necessary, we have to do our own subclass.

Marcello Stanisci

2017-05-23 20:26

reporter   ~0012153

@12151: I thought that we wanted to fire every testcase class coming from Django,
but yes, there is no strong reason to not mix things when it's necessary.

Marcello Stanisci

2017-12-23 11:56

reporter   ~0012703

The TestCase class from Django turned to be very useful, especially thanks to
the 'assertJSONEqual' method and other helpers it has over the "bare" Python's
unittest. Besides, now (88bef48) 'make check' does test the launcher against a
 database which is not found, so this bug is not that worth working on IMO.

Issue History

Date ModifiedUsernameFieldChange
2017-05-22 14:38Marcello StanisciNew Issue
2017-05-22 14:38Marcello StanisciStatusnew => assigned
2017-05-22 14:38Marcello StanisciAssigned To => Marcello Stanisci
2017-05-23 19:44Marcello StanisciNote Added: 0012150
2017-05-23 19:51Florian DoldNote Added: 0012151
2017-05-23 19:55Florian DoldNote Added: 0012152
2017-05-23 20:26Marcello StanisciNote Added: 0012153
2017-12-14 14:55Christian GrothoffProduct Version => git (master)
2017-12-14 14:55Christian GrothoffTarget Version => 0.6
2017-12-23 11:56Marcello StanisciStatusassigned => informing
2017-12-23 11:56Marcello StanisciResolutionopen => no change required
2017-12-23 11:56Marcello StanisciNote Added: 0012703
2017-12-28 16:28Christian GrothoffFixed in Version => 0.5
2017-12-28 16:28Christian GrothoffTarget Version0.6 => 0.5
2018-04-15 18:34Christian GrothoffStatusinforming => closed
2022-08-23 18:26Christian GrothoffCategorybank (demonstrator) => py bank (demonstrator, obsolete)
2023-12-03 00:23Christian GrothoffCategorypy bank (demonstrator, obsolete) => obsolete componet
2023-12-11 19:08Florian DoldCategoryobsolete componet => obsolete component