All bugs are tracked in https://bugzilla.mozilla.org/.
Write up a new bug:
There are multiple components to choose. If in doubt use
Everything runs in a Docker container. Thus Socorro requires fewer things to get started and you’re guaranteed to have the same setup as everyone else and it solves some other problems, too.
2.3. Python code conventions¶
All Python code files should have an MPL v2 header at the top:
# This Source Code Form is subject to the terms of the Mozilla Public # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/.
Python code should follow PEP-8.
Max line length is 100 characters.
To run the linter, do:
$ make lint
If you hit issues, use
2.5. Git conventions¶
First line is a summary of the commit. It should start with one of the following:
Fixes bug nnnnnnn
The first, when it lands, will cause the bug to be closed. The second one does not.
After that, the commit should explain why the changes are being made and any notes that future readers should know for context or be aware of.
2.6. Pull requests¶
Pull request summary should indicate the bug the pull request addresses.
Pull request descriptions should cover at least some of the following:
- what is the issue the pull request is addressing?
- why does this pull request fix the issue?
- how should a reviewer review the pull request?
- what did you do to test the changes?
- any steps-to-reproduce for the reviewer to use to test the changes
2.7. Code reviews¶
Pull requests should be reviewed before merging.
Style nits should be covered by linting as much as possible.
Code reviews should review the changes in the context of the rest of the system.
Dependencies for all parts Socorro are in
requirements.txt. They need to be
pinned and hashed. Use hashin.
For example, to add
foobar version 5:
hashin -r requirements.txt foobar==5
Then rebuild your docker environment:
If there are problems, it’ll tell you.
Documentation for Socorro is build with Sphinx and is available on ReadTheDocs. API is automatically extracted from docstrings in the code.
To build the docs, run this:
$ make docs
2.10. Running tests¶
The tests in
socorro/unittests/ use pytest.
The tests in
webapp-django/ use Nose.
To run the tests, do:
$ make dockertest
That runs the
/app/docker/run_test.sh script in the webapp container using
To run specific tests or specify arguments, you’ll want to start a shell in the test container:
$ make dockertestshell
Then you can run pytest or the webapp tests as you like.
Running all the unittests:
Running a directory of unittests:
app@...:/app$ pytest socorro/unittest/processor/
Running a file of unittests:
app@...:/app$ pytest socorro/unittest/processor/test_processor_app.py
Running webapp tests (make sure you run
./manage.py collectstatic first):
app@...:/app/webapp-django$ ./manage.py test
Running a directory of webapp tests:
app@...:/app/webapp-django$ ./manage.py test crashstats/home/tests/
Running a file of tests:
app@...:/app/webapp-django$ ./manage.py test crashstats/home/tests/test_views.py
2.11. Writing tests¶
For webapp tests, put them in the
tests/ directory of the appropriate app in
For other tests, put them in
2.11.1. Mock usage¶
Mock is a python library for mocks objects. This allows us to write isolated tests by simulating services beside using the real ones. Best examples is existing tests which admittedly do mocking different depending on the context.
Tip! Try to mock in limited context so that individual tests don’t affect other tests. Use context managers and instead of monkey patching imported modules.