PDQTest 2.0 release
PDQTest 2.0 is finally out!
PDQTest was created back in January 2017 and aside from being used on Declarative Systems modules and at few select clients, no one else seems to have heard of it.
PDQTest is 100% free software (Apache 2.0 license) and came about because the current crop of tools were just too hard to use. The main aim of PDQTest is to let you acceptance test code in the simplest and quickest way possible.
We run Docker-in-Docker with systemd running as main process in order to let
users write tests that any sysadmin could understand. Since we’re running in a
controlled, disposable environment, we can subvert the entire operating system
and get it to test exactly what we want. For example, we can replace binaries
such as sysctl, realmd and even ls with simple python scripts that are
able to test the correct parameters have been received.
This lets us test systems that would normally require network services and even lets us mock whole systems such as AIX.
Here are some examples from different projects:
# We trapped the shutdown command to see when it was called...
@test "mock reports system was rebooted" {
grep OK /tmp/os_patching/system_rebooted.txt
}
# Our test containers run real systemd, so we can configure SSH and check the
# daemon really did start. We could even try to login if we wanted to...
@test "service running" {
systemctl status sshd
}
# Check that a value made it all the way through puppet and was saved
@test "default setting made explicit and saved to file" {
grep "net.ipv4.ip_default_ttl=64" /etc/sysctl.d/80-puppet-net.ipv4.ip_default_ttl.conf
}
For a long time PDQTest only supported Linux, which meant Windows projects had to get by with regular RSpec tests and users had to run manual testing.
In addition, PDK was was released and with the arrival of Puppet 6, the
puppet module build command went away.
Clearly, a refresh was needed.
PDQTest 2.0 brings:
- PDK compatibility
- Windows support (experimental - using PATS to write tests in powershell)
- Appveyor Support (slow - PDK-1069)
- In-place testing (eg run acceptance tests on Bitbucket Pipelines)
Because PDQTest lets you run real code on a real system, it lets users find bugs that wouldn’t normally be found until code hits production.
Here’s some of the more memorable PDQTest 1.x moments:
- Our first PDQTest user mocked an entire database server installation by replacing OS binaries with fake python scripts and was able to test the installation of a large database server in seconds, not hours
- One of our customers was puzzled because PDQTest was failing for one of his projects. Turned out that PDQTest was correct, his dev team had mis-packaged an application and this would have duly failed in production had he not caught this early by trying to run the application for real inside a container
- Real test driven development: With PDQTest, you can write your tests with BATS and then write puppet code to make the tests pass, all from the comfort of your IDE
We’d love to hear community feedback on PDQTest!