Changeset 12924 for main/waeup.kofa/trunk/docs
- Timestamp:
- 11 May 2015, 13:35:06 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
main/waeup.kofa/trunk/docs/source/userdocs/testing.rst
r12921 r12924 4 4 ************************** 5 5 6 DocTests 6 Kofa's Python code is being tested automaticallyy. The developers' 7 goal is to reach 100% code coverage by Kofa's test runners, which 8 means that each single line of code is passed at least one time when 9 running the tests. 10 11 Why testing? Testing makes sure that our code works properly under 12 given sets of conditions and, only comprehensive testing ensures 13 that changing or customizing the code does not break existing 14 functionality. Why *automated* testing? Simply because no developer 15 likes to click around the user interface to check tons of 16 functionality. In Kofa more than 1100 tests, with dozens of actions 17 per test, are being executed each time when the testrunner is 18 started. This job can't be done manually. 19 20 There are two different ways to test the code of a web application 21 automatically: *unit tests* and *functional tests*. The goal of unit 22 testing is to isolate each part of the program and show that the 23 individual parts are correct. Functional tests of a web application 24 are more wholistic, they require a running web application in the 25 background with even a working (temporary) database. Functional 26 tests are typically linked to a particular use case, they are 27 interacting with the portal as a user would. That implies that 28 functional testing has to make use of a test browser. A test browser 29 does the same job as normal web browser do, except for visualizing 30 the rendered html code. 31 32 There are also two different ways to integrate tests, either 33 functional or unit, into a Python package: *doc tests* (or doctests) 34 and *Python tests*. Python test modules are a collection of 35 isolatable Python test cases. A test case combines a collection of 36 unit test methods which are being executed by the testrunner one 37 after the other. Python test modules are automatically identified by 38 means of their filenames which start with ``test_``. In contrast, 39 doctests can be wrapped up in simple text files (ending with 40 ``.txt``), or they can be put into docstrings of the application's 41 source code itself. Common to all doctests is that they are based on 42 output from the standard Python interpreter shell (indicated by the 43 interpreter prompt ``>>>``. The doctest runner parses all ``py`` and 44 ``txt`` files in our package, executes the interpreter commands 45 found and compares the output against an expected value. Example:: 46 47 Python's `math` module can compute the square root of 2: 48 49 >>> from math import sqrt 50 >>> sqrt(2) 51 1.4142135623730951 52 53 Why wrapping tests into documentation? An objective of testdriven 54 software development is also the documentation of the 'Application 55 Programming Interface' (API) and, to a certain extent, providing a 56 guideline to users, how to operate the portal. The first is mainly 57 done in the docstrings of Python modules which present an expressive 58 documentation of the main use cases of a module and its components. 59 The latter is primarily done in separate ``txt`` files. 60 61 When starting the development of Kofa, we relied on writing a 62 coherent documentation including doctests in restructured text 63 format. During the software development process the focus shifted 64 from doctesting to pure Python testing with a lot of functional 65 tests inside. It turned out that Python tests are easier to handle 66 and more powerful. Drawback is, that these tests cannot easily be 67 integrated into the Sphinx documentation project (the documentation 68 which you are reading right now). However, we will list some of 69 these tests and try to explain what they are good for. 70 71 72 Doctests 7 73 ======== 8 74 … … 74 140 75 141 76 Python Tests77 =========== =142 Pythontests 143 ===========
Note: See TracChangeset for help on using the changeset viewer.