Skip to content

Commit e266e06

Browse files
committed
Clearing up some old ideas
1 parent 28c63f1 commit e266e06

File tree

1 file changed

+24
-6
lines changed

1 file changed

+24
-6
lines changed

docs/testing.rst

Lines changed: 24 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -7,9 +7,18 @@ Simple testing in Python
77
What we should test ?
88
=====================
99

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.
1322

1423
Unit testing
1524
=============
@@ -191,9 +200,14 @@ Full code
191200
if __name__ == '__main__':
192201
unittest.main()
193202

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+
194206
mounttab.py
195207
============
208+
196209
Here we have only one function *mount_details()* doing the parsing and printing mount details.
210+
197211
::
198212

199213
import os
@@ -208,7 +222,7 @@ Here we have only one function *mount_details()* doing the parsing and printing
208222
for line in fd:
209223
line = line.strip()
210224
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=' ')
212226
if len(words) > 5:
213227
print('(%s)' % ' '.join(words[3:-2]))
214228
else:
@@ -221,7 +235,9 @@ Here we have only one function *mount_details()* doing the parsing and printing
221235

222236
After refactoring
223237
=================
238+
224239
Now we refactored the code and have one new function *parse_mounts* which we can test easily.
240+
225241
::
226242

227243
import os
@@ -304,19 +320,20 @@ and the test code for the same.
304320

305321
Test coverage
306322
=============
323+
307324
Test coverage is a simple way to find untested parts of a codebase. It does not
308325
tell you how good your tests are.
309326

310327
In Python we already have a nice coverage tool to help us. You can install it in Fedora
311328

312329
::
313330

314-
# yum install python-coverage
331+
# dnf install python3-coverage
315332

316333
Or using `pip`.
317334
::
318335

319-
$ pip install coverage
336+
$ python3 -m pip install coverage
320337

321338
Coverage Example
322339
================
@@ -332,3 +349,4 @@ Coverage Example
332349
mounttest 14 0 100%
333350
-----------------------------------------
334351
TOTAL 35 7 80%
352+

0 commit comments

Comments
 (0)