Since my prior post on Contributing to OpenStack, I liked the idea of using some automated tests to validate functionality and specifically, the corner cases that could arise when playing with the code.
Most of the errors fixed so far on stampy, were related with some pieces of the code not properly handling UTF or some information returned, etc and still it has improved, the idea of ensuring that prior errors were not put back into the code when some other changes were performed, started to arise to be a priority.
For implementing them, I made use of nose
, which can be executed with nosetests
and are available on Fedora as ‘python-nose’ and to provide further automation, I’ve also relied on tox
also inspired n what OpenStack does.
Let’s start with tox
: once installed, a new configuration file is created for it, defining the different environments and configuration in a similar way to:
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 |
|
This file, defines two environments, one for validating pep8 for the python formatting and another one for validating python 2.7.
The environment definition for the tests, also performs some commands like executed the
aforementioned nosetests
to run the defined unit tests.
Above tox.ini
also mentions requirements.txt
and test-requirements.txt
, which define the python packages required to validate the program, that will be automatically installed by tox on a virtualenv
, so the alternate versions being used, doesn’t interfere with the system-wide ones we’re using.
About the tests themselves, as nosetests
does automatic discovery of tests to perform, I’ve created a new folder named tests/
and placed there some files in alphabetically order:
1 2 3 4 5 6 7 8 9 |
|
First one test_00-setup
takes the required commands to define the environment, as on each validation run of tox
, a new environment should be available not to mask errors that could be overlooked.
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 |
|
This file creates the database if none is existing and defines some sample values, like DEBUG level, url for contacting telegram API servers, or even a token that can be used to test the functionality for sending messages.
Also, if the database is already existing, empties the karma table, quotes (and sets sequence to 0 to simulate TRUNCATE which is not available on
sqlite
)
An unittest
is specified under the class inherited from TestCase
imported from unittest
, there for each one of the tests we want to performed, a new ‘definition’ is created and after it an assert is used, for example assertEqual
validates that the function call returns the value provided as secondary argument, failing otherwise.
From that point, the tests are performed again in alphabetically order, so be careful in the naming of each tests or define a sequence number to use a top-to-bottom approach that will be probably easier to understand.
For example, for karma changes we’ve:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
Which starts by putting a known karma on a word, validating, verifying the query, update the value by a positive number and later, decrease it with a negative one.
For the aliases, we use a similar approach, as we also play with the karma changes when an alias is defined:
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 |
|
Where an alias is created, verified, karma in creased on the word with an alias, and then the aliased value.
As noted in the above example, the individual function for the karma doesn’t take into consideration the aliases so this must be handled by processing a message set via process(messages)
which has been also modified as well as other functions to allow the implementation of individual tests for them.
This will for sure end up with some more code rewriting so the functions can be fully tested individually and as a whole, to ensure that the bot behaves as intended… and many more tests to come to the code.
As an end, an example of the execution of tox and the results raised:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
If you’re using a CI system, like ‘Travis’, which is also available to https://github.com
repositories, a .travis.yml
can be added to the repository to ensure those tests are performed automatically on each code push:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
Enjoy!
Comments