Project to store the questions and answers for interview.
- Global Development Requirements
- Running and working with the app locally
- Testing
- Project structure
- Initial setup
- Docker
- Other
- Python 3.11
- Django >= 4.0
- Postgresql >= 14.5
- Docker and docker-compose (optional)
Instead of the standard runserver manage command (./manage.py runserver
) you can use
(venv) $ ./manage.py runserver_plus
to run the app. This will enhance the server with the Werkzeug interactive debugger that will allow you to interact with your code (debug it) in the browser, when it throws an exception instead of returning a valid response.
Similarly, instead of ./manage shell
you can use
(venv) $ ./manage.py shell_plus
and have your models (and a few frequently needed classes and modules) will be automatically imported.
pytest
used for tests.
Check https://djangostars.com/blog/django-pytest-testing/ article if not familiar.
Use following command to run tests before commit (With this call, pytest will spawn a number of workers processes equal to the number of available CPUs, and distribute the tests randomly across them):
pytest -n auto
Or during development:
pytest -s -vv --no-migrations --reuse-db --tb=short
Explanation (some flags used in pytest.ini
):
-s
- don't capture output. By default pytest captures standard output while running tests.-vv
- increases the verbosity level. Or use-v
It’s only if a test fails that it shows the captured output.--no-migrations
: This flag is specific to Django projects. It disables the execution of database migrations during testing.--reuse-db
- after the test run, the test database will not be removed.--tb=short
- sets the level of detail for the displayed traceback output when a test fails. In this case, short is the value specified. It provides a shorter traceback with only the most relevant information about the failure.
Optional:
--disable-warnings
- to disable warnings during the tests.--sw
- run tests instepwise
move. The test suite will run until the first failure and then stop. At the next invocation, tests will continue from the last failing test and then run until the next failing test.
Caveat: If there were updates in the database, with you need to specify --create-db
flag to update database with the last changes.
.
├── .github/ - github actions
├── requirements/
│ ├── base.txt
│ ├── dev.txt
│ └── prod.txt
├── src/ - source directory
│ ├── apps/ - applications with business logic
│ ├── settings/ - project settings
│ ├── api_urls.py
│ └── urls.py
├── tests/
│ ├── apps/ - tests for apps
│ └── conftest.py - file with fixtures
├── .env.example - file with environment varialbes
├── Dockerfile
├── README.md
├── docker-compose.yml
├── manage.py
├── pyproject.toml
└── pytest.ini
- Clone the project
- Create an env dir and activate
python3.11 -m venv venv
source venv/bin/activate
- Install requirements.txt
(venv) $ pip install -r requirements/dev.txt
- Setup
.env
file. Copy and rename.env.example
->.env
and fill with proper values. Checkdjango-environ
for details.
Override database configs in your .env
file if necessary.
postgres command to setup the DB
psql
#: CREATE DATABASE pythonjunior WITH OWNER postgres;
Before being able to run the project, you'll at least have to set up the database. (Remember, local settings go into the local.py file.) PostgreSQL is the db used for production, and multiple PostgreSQL-specific extensions are used.
After setting up the db, you should run
(venv) $ ./manage.py migrate
pre-commit install
This will enable black, flake8 and default pre-commit hooks such as end-of-file-fixer.
This command will format all changed files properly and also highlight problematic places
pre-commit
Then add any changed files to commit and try committing the changes.
Docker and docker-compose also available
docker-compose build
docker-compose up
or
docker-compose up --build
- Update TOC in the
README.md
file (details)
markdown-toc -h 3 -t github README.md