The minimal requirement for running the testsuite is ``py.test``. You can
The minimal requirement for running the testsuite is ``py.test``. You can
install it with::
install it with::
@ -68,3 +68,47 @@ of ``pytest``. You can install it with::
The ``tox`` command will then run all tests against multiple combinations
The ``tox`` command will then run all tests against multiple combinations
Python versions and dependency versions.
Python versions and dependency versions.
Running test coverage
---------------------
Generating a report of lines that do not have unit test coverage can indicate where
to start contributing. ``pytest`` integrates with ``coverage.py``, using the ``pytest-cov``
plugin. This assumes you have already run the testsuite (see previous section)::
pip install pytest-cov
After this has been installed, you can output a report to the command line using this command::
py.test --cov=flask tests/
Generate a HTML report can be done using this command::
py.test --cov-report html --cov=flask tests/
Full docs on ``coverage.py`` are here: https://coverage.readthedocs.io
Caution
=======
pushing
-------
This repository contains several zero-padded file modes that may cause issues when pushing this repository to git hosts other than github. Fixing this is destructive to the commit history, so we suggest ignoring these warnings. If it fails to push and you're using a self-hosted git service like Gitlab, you can turn off repository checks in the admin panel.
cloning
-------
The zero-padded file modes files above can cause issues while cloning, too. If you have
::
[fetch]
fsckobjects = true
or
::
[receive]
fsckObjects = true
set in your git configuration file, cloning this repository will fail. The only solution is to set both of the above settings to false while cloning, and then setting them back to true after the cloning is finished.
@ -71,7 +71,8 @@ Now in each request handling function you can access `g.db` to get the
current open database connection. To simplify working with SQLite, a
current open database connection. To simplify working with SQLite, a
row factory function is useful. It is executed for every result returned
row factory function is useful. It is executed for every result returned
from the database to convert the result. For instance, in order to get
from the database to convert the result. For instance, in order to get
dictionaries instead of tuples, this could be inserted into ``get_db``::
dictionaries instead of tuples, this could be inserted into the ``get_db``
function we created above::
def make_dicts(cursor, row):
def make_dicts(cursor, row):
return dict((cursor.description[idx][0], value)
return dict((cursor.description[idx][0], value)
@ -79,10 +80,26 @@ dictionaries instead of tuples, this could be inserted into ``get_db``::
db.row_factory = make_dicts
db.row_factory = make_dicts
Or even simpler::
This will make the sqlite3 module return dicts for this database connection, which are much nicer to deal with. Even more simply, we could place this in ``get_db`` instead::
db.row_factory = sqlite3.Row
db.row_factory = sqlite3.Row
This would use Row objects rather than dicts to return the results of queries. These are ``namedtuple`` s, so we can access them either by index or by key. For example, assuming we have a ``sqlite3.Row`` called ``r`` for the rows ``id``, ``FirstName``, ``LastName``, and ``MiddleInitial``::
>>> # You can get values based on the row's name
>>> r['FirstName']
John
>>> # Or, you can get them based on index
>>> r[1]
John
# Row objects are also iterable:
>>> for value in r:
... print(value)
1
John
Doe
M
Additionally, it is a good idea to provide a query function that combines
Additionally, it is a good idea to provide a query function that combines
getting the cursor, executing and fetching the results::
getting the cursor, executing and fetching the results::