First, changes to pykickstart can potentially disrupt many other software components. Additionally, automated testing of the anaconda installer has a lot of moving parts. A fully automated system needs a scheduling mechanism, a breadth of hardware to install on, a reporting mechanism (live progress and results), hardware to support remote console+kvm, and hardware to support power cycling failed/timeout tests … oh and more hardware :).

While some of the software support to enable some of the above is coming online with the beaker and nitrate projects. A short-term win is to test the individual pieces that are used to build an installable product (yum, rpm, pyparted, pykickstart, NetworkManager).

Why unit tests?

Unit testing is one of the fastest ways to provide test feedback to a developer. Typically, unit tests do not require additional infrastructure (test case management, test harness, test results storage etc…). As soon as the developer fixes a bug or adds a new feature, [s]he can get immediate test feedback. The don’t have to commit their changes, submit a build, wait until their changes are pulled into rawhide.

The barrier to entry is very low with pykickstart. If you’ve ever seen or written a kickstart file before … you should be familiar with the tests.