PyColorado / boulderpython.org

Boulder Python Meetup Website
http://boulderpython.org
MIT License
5 stars 4 forks source link

Tests #12

Closed frankV closed 6 years ago

frankV commented 6 years ago

There really aren't any.

We should keep this open to track progress on implementing a test suit of some sort.

frankV commented 6 years ago

I added a fuller test suite (well, the beginning of one). The last test module relied on the run.py application server, which used gunicorn as the application instance. This wasn't a good idea as Flask already has a test client and using the pre-fork model of gunicorn when testing requests was gonna cause headaches by obfuscating tracebacks.

What this meant for the codebase was that I had to refactor both run.py and application.app. To make testing with py.test fixtures easy - we really needed to use the Flask factory pattern. Since we're using Flask 0.12, we can utilize it's baked in app manager (runs click under the hood). So run.py is totally different, but better (I hope).

There is one little annoying detail about the flask command in that you must set an env var (FLASK_APP) that identifies your application file. Since we're optionally including pipenv, you can include a .env file with FLASK_APP=run.py so it's available everytime you run pipenv shell.

Updates to run/test commands:

I'll be merging this into develop soon.

frankV commented 6 years ago

Coverage report is falsely tracing imports, and class/function definitions. I don't think coverage is starting early enough and I would like to continue using the pytest-cov plugin. There's an issue open addressing this and I have asked for specific advice to our case: https://github.com/pytest-dev/pytest-cov/issues/184

frankV commented 6 years ago

Coverage issue was due to the flask/click cli command I created to wrap py.test. That was making an instance of flask and our app well before py.test, let alone coverage, were ever invoked. Solution was: use py.test command.