How to Write Tests
You most probably know why it's a good idea to write tests, but let's name some of the reasons here:
- Automatic tests can run 24/7, which is way way more effective than testing code manually
- Tests can capture what a code is expected to do and, if well done, it does not let us introduce regressions
- Each code will eventually break, but you may not find out without tests
- People might be afraid of a change if they can't guarantee all the code still does what it's expected to do - tests give you the confidence for change
- Bad and ugly test makes you write a good API
- Test output (RSpec) can help with documentation
Unit tests with RSpec
Here are some basic rules that all YaST projects should follow regarding RSpec tests:
- Test must be readable - everyone has to easily understand what the test actually tests
- It's easy-to-maintain - no hacks, no magic
- Needs to cover the whole code, otherwise you would feel a false sense of security
- A test suite should be comprehensive but every individual test on it should be specific
- Test all aspects of a method (depending on context, and input), see Examples
- Uses "allow" for queries, but "expect" commands, see Examples
- Expectation in "it" block - must be explicit, see Examples
- Description of a test should describe the behavior - you should get the idea just by reading the "it" / "context", see Examples
Adding more and more unit tests obviously means that the time needed for running the complete test suite also increases. And at some point it becomes annoying.
Normally the RSpec executes the tests in sequence, one by one. However, using the parallel_tests Ruby gem it is possible to run the tests in parallel.
rake unit:test includes support for running parallel tests, just make sure
you have installed the
ruby<version>-rubygem-parallel_tests package otherwise
the task will use the standard (sequential) RSpec. Add the gem to
BuildRequires dependency if you want to use it also during the RPM package build.
To activate the parallel tests just create a
.rspec_parallel file in the Git
root directory. The suggested content is
--format progress --format ParallelTests::RSpec::RuntimeLogger --out tmp/parallel_runtime_rspec.log
This will use the "dot" progress output and save the runtime statistics for each test file to the specified log file. Next time it will be used to split the tests into more balanced test groups. That means the very first run will be less effective and probably it will take a bit more time.
Obviously there must not be any dependencies or race conditions between the tests otherwise it will fail.
You can force running parallel tests using
PARALLEL_TESTS=1 rake test:unit,
that is great for checking if the current tests can be run in parallel.
Or force classic sequential RSpec with
PARALLEL_TESTS=0 rake test:unit
to find whether a test failure might be caused by some race condition.
See the test:unit description
for more details.
You can check a full example in the yast2-storage-ng package.
Integration tests with openQA
Integration tests for all the openSUSE distributions are performed by the openSUSE openQA instance. When possible, is desirable to add tests for new features or bug fixes in YaST to the opensuse distri, so they can be integrated in the continuous testing process of the distribution.
See the links section for more information about how to develop openQA tests for YaST.
AutoYaST integration tests
AutoYaST has its own framework for running integration tests by using Veewee, Vagrant and Pennyworth. See the corresponding Github page for more information.
Tests for the command line with the Test Anything Protocol
Apart from the usual user interface, some YaST modules also offer a non-interactive command line interface. In order to test that CLI, simple TAP-compliant scripts are used. TAP, the Test Anything Protocol, is a simple text-based interface between testing modules in a test harness.
The CLI testing scripts are placed in a
t directory at the root of each
YaST module and are executed using the command
prove. This command is a
runner for the Test Anything Protocol which has a stdio interface and thus
is well suited for command line tests. The program is conveniently part of
a base openSUSE system, in
The scripts operate directly on the running system, which means that, although
most of them try to clean up after themselves, they can reconfigure the system.
As a consequence, they must be executed in a scratch virtual machine. For that
purpose, a specific openQA test module called
is used to run the scripts in a safe way. All modules with CLI integration tests
must be explicitly included in