Sample app in repo's travis build fails

[nam20485]

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?

[MikeTheCanuck]

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.

1. if the only thing we're validating is that the Django-to-database driver is operating correctly, then having the Travis-based testing just use a sqlite DB should be sufficient
2. if we'd like to extend this validation to ensure that the Django-to-PostgreSQL driver is operating correctly, then we ought to stand up a dummy PostgreSQL database, and configure Travis settings with creds that can authenticate to the PostgreSQL server
3. if our intention with testing the data layer is to verify that Django code is successfully retrieving actual data from the database layer, then neither of these strategies makes any sense (not for the sample, and not for any of our actual API repos)

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.

[nam20485]

This is blocked pending resolution of #82. Once we decide on and implement a unit testing strategy this issue will become resolved.