Open nam20485 opened 6 years ago
This can be solved, and should be solved, but the question is "what are we really trying to accomplish with that level of testing?"
I was mystified all last year by testing tactics that seemed to "touch a magical database" that I didn't have to manage, that never had to be cleaned up, and which didn't have any particular data - and which somehow was meant to verify that Django and its data layer were copacetic.
If we just want to make this error go away and grapple with the more fundamental "what is our testing strategy trying to prove" question later, then I'd recommend (1) and move on.
This is blocked pending resolution of #82. Once we decide on and implement a unit testing strategy this issue will become resolved.
The travis configuration we added to this repo functions for the sample app, prior to generating a quickstart app and forking, as well as after for the generated and forked quickstart apps. It functions successfully for the generated app, but the travis build for the sample app does not complete successfully. This is due to the fact that there is not a DB that the sample app can connect to for the test.sh portion of the travis build. (Quickstart-generated apps for backend repos will necessarily their own DB to connect to so this is only an issue for the sample app).
Also, the sample does not depend on any specific models or schema existing in the database it connects to, so a blank postgres DB would probably suffice.
We need to decide what the procedure is for running test.sh -p during the travis build, specifically how the python manage.py test command is going to work, and more specifically, what DB it will connect to. There are a couple options I see off the top of my head:
1.) Change production testing to use a different DB like sqlite 2.) Create a live instance of a DB that the sample app can use.
What are your all thoughts here?