Allow running pytest from local host

[ebreton]

Running tests should be lightning fast. I was (maybe un-rightely) using the script from scripts/tests-local.sh, which takes care of building fresh containers, starting them and then running the tests.

I will keep this process for automatic tests (probably on git hooks)...
This PR provides a way to run pytest locally during base development

Therefore

$ cookiecutter full-stack-fastapi-postgresql/ --no-input
$ cd base-project
$ docker-compose up -d
$ cd backend/app/
$ pipenv install --dev
...
$ pipenv shell
$ pytest

and tada ! 🎉

================================= test session starts ==================================
platform darwin -- Python 3.7.3, pytest-4.3.0, py-1.7.0, pluggy-0.8.1
rootdir: /Users/emb/git-repos/github/base-project/backend/app, inifile:
plugins: celery-4.2.1
collected 17 items

app/tests/api/api_v1/test_celery.py .                                            [  5%]
app/tests/api/api_v1/test_token.py ..                                            [ 17%]
app/tests/api/api_v1/test_user.py ......                                         [ 52%]
app/tests/crud/test_user.py ........                                             [100%]

============================== 17 passed in 6.16 seconds ===============================

There is however this new .env file that the users should be aware of... but that definitevely worth the price IMHO 👶

[tiangolo]

Thanks, I'll check it soon.

[tiangolo]

The problem here is that the .env file will end up in the container too, and it can create problems there.

Apart from requiring another file with variables that the user has to take care of.

Also, you can run more or less the same with:

cookiecutter full-stack-fastapi-postgresql/ --no-input
cd base-project
docker-compose up -d
docker-compose exec backend-tests /tests-start.sh

The benefit is that the tests are being run in an environment equivalent to production, the server is communicating with its own DB, independent of if there are other DBs up in the same port or similar things.

On another note, I plan on including the tests in the same image as the backend, so they can be run separately but they can also run in the same container, this will allow enabling and using code coverage, inside the containers.

[ebreton]

You are right, I missed the docker-compose exec backend-tests /tests-start.sh

I am looking forward test coverage (which does not look simple between multiple containers) !

[tiangolo]

Great, thanks!