You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/testing.rst
+24-6Lines changed: 24 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,9 +7,18 @@ Simple testing in Python
7
7
What we should test ?
8
8
=====================
9
9
10
-
If possible everything in our codebase, each and every function. But it depends as a choice
11
-
of the developers. You can skip it if it is not practical to write a robust test. As Nick Coghlan
12
-
said in a guest session -- *... with a solid test suite, you can make big changes, confident that the externally visible behavior will remain the same*
10
+
If possible everything in our codebase, each and every function. But it depends
11
+
as a choice of the developers. You can skip it if it is not practical to write
12
+
a robust test. As `Nick Coghlan <http://www.curiousefficiency.org>`_ said in a
13
+
guest session -- *... with a solid test suite, you can make big changes,
14
+
confident that the externally visible behavior will remain the same*
15
+
16
+
To have effective tests, you should remember to write/split your code in
17
+
smaller functions which can be tested separately. It is very easy to keep
18
+
writing longer functions, which can do a lot of things at once. But, it will be
19
+
increasingly difficult to test those functions. If you keep them short, and
20
+
make sure that one function does one thing well, it will help to write better
21
+
test cases.
13
22
14
23
Unit testing
15
24
=============
@@ -191,9 +200,14 @@ Full code
191
200
if __name__ == '__main__':
192
201
unittest.main()
193
202
203
+
204
+
.. note:: The following example is for Linux only, you will have to modify the code so that it can find mount details in other operating systems properly.
205
+
194
206
mounttab.py
195
207
============
208
+
196
209
Here we have only one function *mount_details()* doing the parsing and printing mount details.
210
+
197
211
::
198
212
199
213
import os
@@ -208,7 +222,7 @@ Here we have only one function *mount_details()* doing the parsing and printing
208
222
for line in fd:
209
223
line = line.strip()
210
224
words = line.split()
211
-
print()'%s on %s type %s' % (words[0],words[1],words[2]), end=' ')
225
+
print(f'{words[0]} on {words[1]} type {words[2]}', end=' ')
212
226
if len(words) > 5:
213
227
print('(%s)' % ' '.join(words[3:-2]))
214
228
else:
@@ -221,7 +235,9 @@ Here we have only one function *mount_details()* doing the parsing and printing
221
235
222
236
After refactoring
223
237
=================
238
+
224
239
Now we refactored the code and have one new function *parse_mounts* which we can test easily.
240
+
225
241
::
226
242
227
243
import os
@@ -304,19 +320,20 @@ and the test code for the same.
304
320
305
321
Test coverage
306
322
=============
323
+
307
324
Test coverage is a simple way to find untested parts of a codebase. It does not
308
325
tell you how good your tests are.
309
326
310
327
In Python we already have a nice coverage tool to help us. You can install it in Fedora
0 commit comments