1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
============
Adding Tests
============
We will now add tests for the models and views as well as a few functional
tests in a new ``tests`` subpackage. Tests ensure that an application works,
and that it continues to work when changes are made in the future.
The file ``tests.py`` was generated as part of the ``alchemy`` scaffold, but it
is a common practice to put tests into a ``tests`` subpackage, especially as
projects grow in size and complexity. Each module in the test subpackage
should contain tests for its corresponding module in our application. Each
corresponding pair of modules should have the same names, except the test
module should have the prefix ``test_``.
We will move parts of ``tests.py`` into appropriate new files in the ``tests``
subpackage, and add several new tests.
Start by creating a new directory and a new empty file ``tests/__init__.py``.
.. warning::
It is very important when refactoring a Python module into a package to
be sure to delete the cache files (``.pyc`` files or ``__pycache__``
folders) sitting around! Python will prioritize the cache files before
traversing into folders and so it will use the old code and you will wonder
why none of your changes are working!
Test the views
==============
We'll create a new ``tests/test_views.py`` file, adding tests for each view
function we previously added to our application. As a result, we'll *delete*
the ``ViewTests`` class that the ``alchemy`` scaffold provided, and add four
other test classes: ``ViewWikiTests``, ``ViewPageTests``, ``AddPageTests``, and
``EditPageTests``. These test the ``view_wiki``, ``view_page``, ``add_page``,
and ``edit_page`` views.
Functional tests
================
We'll test the whole application, covering security aspects that are not
tested in the unit tests, like logging in, logging out, checking that
the ``basic`` user cannot edit pages it didn't create, but the ``editor`` user
can, and so on.
View the results of all our edits to ``tests`` subpackage
=========================================================
Open ``tutorial/tests/test_views.py``, and edit it such that it appears as
follows:
.. literalinclude:: src/tests/tutorial/tests/test_views.py
:linenos:
:language: python
Open ``tutorial/tests/test_functional.py``, and edit it such that it appears as
follows:
.. literalinclude:: src/tests/tutorial/tests/test_functional.py
:linenos:
:language: python
.. note::
We're utilizing the excellent WebTest_ package to do functional testing
of the application. This is defined in the ``tests_require`` section of
our ``setup.py``. Any other dependencies needed only for testing purposes
can be added there and will be installed automatically when running
``setup.py test``.
Running the tests
=================
We can run these tests by using ``setup.py test`` in the same way we did in
:ref:`running_tests`:
On UNIX:
.. code-block:: bash
$ $VENV/bin/python setup.py test -q
On Windows:
.. code-block:: text
c:\pyramidtut\tutorial> %VENV%\Scripts\python setup.py test -q
The expected result should look like the following:
.. code-block:: text
....................
----------------------------------------------------------------------
Ran 20 tests in 0.524s
OK
Process finished with exit code 0
.. _webtest: http://docs.pylonsproject.org/projects/webtest/en/latest/
|
