1 | .. _testing: |
---|
2 | |
---|
3 | Testing |
---|
4 | ******* |
---|
5 | |
---|
6 | Introduction |
---|
7 | ============ |
---|
8 | |
---|
9 | Kofa's Python code is being tested automatically. The developers' |
---|
10 | goal is to reach 100% code coverage by Kofa's test runners, which |
---|
11 | means that each single line of code is passed at least one time when |
---|
12 | running the tests. |
---|
13 | |
---|
14 | Why testing? Testing makes sure that our code works properly under |
---|
15 | given sets of conditions and, only comprehensive testing ensures |
---|
16 | that changing or customizing the code does not break existing |
---|
17 | functionality. |
---|
18 | |
---|
19 | Why *automated* testing? Simply because no developer likes to click |
---|
20 | around the user interface to check tons of functionality. In Kofa |
---|
21 | more than 1300 tests, with dozens of actions per test, are being |
---|
22 | executed each time when the testrunner is started. This job can't be |
---|
23 | done manually. |
---|
24 | |
---|
25 | What we test: "Unit" and "Functional" Tests |
---|
26 | ------------------------------------------- |
---|
27 | |
---|
28 | There are two different ways to test the code of a web application |
---|
29 | automatically: *unit tests* and *functional tests*. The goal of unit |
---|
30 | testing is to isolate each part of the program and show that the |
---|
31 | individual parts are correct. Functional tests of a web application |
---|
32 | are more wholistic, they require a running web application in the |
---|
33 | background with even a working (temporary) database. Functional |
---|
34 | tests are typically linked to a particular use case, they are |
---|
35 | interacting with the portal as a user would. That implies that |
---|
36 | functional testing has to make use of a test browser. A test browser |
---|
37 | does the same job as normal web browser does, except for visualizing |
---|
38 | the rendered HTML code. |
---|
39 | |
---|
40 | |
---|
41 | How we test: "Python" and "Doctest" Tests |
---|
42 | ----------------------------------------- |
---|
43 | |
---|
44 | There are also two different ways to integrate tests, either |
---|
45 | functional or unit, into a Python package: *Doctest tests* (or doctests) |
---|
46 | and *Python tests*. Python test modules are a collection of |
---|
47 | isolatable Python test cases. A test case combines a collection of |
---|
48 | test methods which are being executed by the testrunner one |
---|
49 | after the other. Python test modules are automatically identified by |
---|
50 | means of their filenames which start with ``test_``. In contrast, |
---|
51 | doctests can be wrapped up in simple text files (ending with |
---|
52 | ``.txt``), or they can be put into docstrings of the application's |
---|
53 | source code itself. Common to all doctests is that they are based on |
---|
54 | output from the standard Python interpreter shell (indicated by the |
---|
55 | interpreter prompt ``>>>``. The doctest runner parses all ``py`` and |
---|
56 | ``txt`` files in our package, executes the interpreter commands |
---|
57 | found and compares the output against an expected value. Example:: |
---|
58 | |
---|
59 | Python's `math` module can compute the square root of 2: |
---|
60 | |
---|
61 | >>> from math import sqrt |
---|
62 | >>> sqrt(2) |
---|
63 | 1.4142135623730951 |
---|
64 | |
---|
65 | Why wrapping tests into documentation? An objective of testdriven |
---|
66 | software development is also the documentation of the 'Application |
---|
67 | Programming Interface' (API) and, to a certain extent, providing a |
---|
68 | guideline to users, how to operate the portal. The first is mainly |
---|
69 | done in the docstrings of Python modules which present an expressive |
---|
70 | documentation of the main use cases of a module and its components. |
---|
71 | The latter is primarily done in separate ``txt`` files. |
---|
72 | |
---|
73 | When starting the development of Kofa, we relied on writing a |
---|
74 | coherent documentation including doctests in restructured text |
---|
75 | format. During the software development process, the focus shifted |
---|
76 | from doctesting to pure Python testing with a lot of functional |
---|
77 | tests inside. It turned out that Python tests are easier to handle |
---|
78 | and more powerful. Drawback is, that these tests cannot easily be |
---|
79 | integrated into the Sphinx documentation project (the documentation |
---|
80 | which you are reading right now). However, we will list some of |
---|
81 | these tests and try to explain what they are good for. |
---|
82 | |
---|
83 | |
---|
84 | Doctest Tests |
---|
85 | ============= |
---|
86 | |
---|
87 | Browsing |
---|
88 | -------- |
---|
89 | |
---|
90 | .. toctree:: |
---|
91 | :maxdepth: 2 |
---|
92 | |
---|
93 | testing/pages |
---|
94 | testing/breadcrumbs |
---|
95 | |
---|
96 | Cataloging |
---|
97 | ---------- |
---|
98 | |
---|
99 | .. toctree:: |
---|
100 | :maxdepth: 2 |
---|
101 | |
---|
102 | testing/catalog |
---|
103 | |
---|
104 | Data Center |
---|
105 | ----------- |
---|
106 | |
---|
107 | .. toctree:: |
---|
108 | :maxdepth: 2 |
---|
109 | |
---|
110 | testing/datacenter |
---|
111 | |
---|
112 | Security |
---|
113 | -------- |
---|
114 | |
---|
115 | .. toctree:: |
---|
116 | :maxdepth: 2 |
---|
117 | |
---|
118 | testing/permissions |
---|
119 | |
---|
120 | Officers |
---|
121 | -------- |
---|
122 | |
---|
123 | .. toctree:: |
---|
124 | :maxdepth: 2 |
---|
125 | |
---|
126 | testing/userscontainer |
---|
127 | |
---|
128 | University |
---|
129 | ---------- |
---|
130 | |
---|
131 | .. toctree:: |
---|
132 | :maxdepth: 2 |
---|
133 | |
---|
134 | testing/app |
---|
135 | |
---|
136 | Academic Section |
---|
137 | ---------------- |
---|
138 | |
---|
139 | .. toctree:: |
---|
140 | :maxdepth: 2 |
---|
141 | |
---|
142 | testing/certcourse |
---|
143 | |
---|
144 | Batch Processing |
---|
145 | ---------------- |
---|
146 | |
---|
147 | .. toctree:: |
---|
148 | :maxdepth: 2 |
---|
149 | |
---|
150 | testing/batchprocessing |
---|
151 | testing/batchprocessing_browser |
---|
152 | |
---|
153 | Access Codes |
---|
154 | ------------ |
---|
155 | |
---|
156 | .. toctree:: |
---|
157 | :maxdepth: 2 |
---|
158 | |
---|
159 | testing/accesscode |
---|
160 | |
---|
161 | |
---|
162 | Python Tests |
---|
163 | ============ |
---|
164 | |
---|
165 | There are hundreds of Python test cases in Kofa with many test |
---|
166 | methods each. Here we present only a few of them. The test methods |
---|
167 | are easy to read. In most cases they are functional and certain |
---|
168 | methods and properties of a test browser are called. Most important |
---|
169 | are `browser.open()` (opens a web page), `browser.getControl()` |
---|
170 | (gets a control button), `browser.getLink()` (gets a link) and |
---|
171 | `browser.contents` (is the HTML content of the opened page). |
---|
172 | |
---|
173 | |
---|
174 | .. _test_suspended_officer: |
---|
175 | |
---|
176 | Suspended Officer Account |
---|
177 | ------------------------- |
---|
178 | |
---|
179 | The first test can be found in |
---|
180 | `waeup.kofa.browser.tests.test_browser.SupplementaryBrowserTests`: |
---|
181 | |
---|
182 | .. literalinclude:: ../../../src/waeup/kofa/browser/tests/test_browser.py |
---|
183 | :pyobject: test_suspended_officer |
---|
184 | |
---|
185 | This test makes sure that a suspended officers can't login but see a |
---|
186 | proper warning message when trying to login. Furthermore, suspended |
---|
187 | officer accounts are clearly marked and a warning message shows up |
---|
188 | if a manager accesses a suspended account, see :ref:`Officers |
---|
189 | <officers>`. |
---|
190 | |
---|
191 | |
---|
192 | .. _test_handle_clearance: |
---|
193 | |
---|
194 | Handle Clearance by Clearance Officer |
---|
195 | ------------------------------------- |
---|
196 | |
---|
197 | This test can be found in |
---|
198 | `waeup.kofa.students.tests.test_browser.OfficerUITests`: |
---|
199 | |
---|
200 | .. literalinclude:: ../../../src/waeup/kofa/students/tests/test_browser.py |
---|
201 | :pyobject: test_handle_clearance_by_co |
---|
202 | |
---|
203 | |
---|
204 | .. _test_handle_courses: |
---|
205 | |
---|
206 | Handle Course List Validation by Course Adviser |
---|
207 | ----------------------------------------------- |
---|
208 | |
---|
209 | This test can be found in |
---|
210 | `waeup.kofa.students.tests.test_browser.OfficerUITests`: |
---|
211 | |
---|
212 | .. literalinclude:: ../../../src/waeup/kofa/students/tests/test_browser.py |
---|
213 | :pyobject: test_handle_courses_by_ca |
---|
214 | |
---|
215 | |
---|
216 | .. _test_batch_editing_scores: |
---|
217 | |
---|
218 | Batch Editing Scores by Lecturers |
---|
219 | --------------------------------- |
---|
220 | |
---|
221 | This test can be found in |
---|
222 | `waeup.kofa.students.tests.test_browser.OfficerUITests`: |
---|
223 | |
---|
224 | .. literalinclude:: ../../../src/waeup/kofa/students/tests/test_browser.py |
---|
225 | :pyobject: test_handle_courses_by_lecturer |
---|