Sure. Unit-tests for code with heavy filesystem usage

Once upon a time …

I’ve been reworking the network configuration part of oVirt Node. Node is now capable of creating bonds and the use of bridge is now optionally.

<history optional=”optional”>

Compared to the layout which was allowed before, these two changes allow a broader range of network layouts.

We are still using soon-to-be-deprecated (?) ifcfg-files for network configuration to configure the individual network devices.\ A bridge consisting of one slave - which is the tagged part of a bond - this will result in at least five (5) ifcfg-files (depending how many bond slaves you are using):

Bridge
Bond (master)
Bond (slave)
Tagged (part of the bond slave)
Loopback

And that’s were unit-tests come into play. I wanted to use unit-tests to cover all possible configurations.

</history>

One goal was to really check the on-disk files, to cover the whole code path. Without any mocking, the unit tests would involve filesystem modifications, so creating and happily deleting files everywhere. That’s

obviously - not so nice.

This began rather cumbersome, I started mock-ing up the access to individual files - and that is boring.

Another try involved using a chroot - but that made to many assumptions about the runtime environment - IMO- and also required root privileges.

The current solution arose quite quick, faking filesystem access by introducing a fake FS. For simplicity I also created a class for file access - this class could then be mocked to redirect all file system related calls to the fake filesystem.

\ Many words, here is how it looks:

The solution works well with mock, and time will tell if it can also cover our other usecases - and Node has a couple of places where we interact with files :)

Finally I can only point you to our unit-test which cover the network setups.

::: {#footer} [ July 9th, 2013 11:04am ]{#timestamp} [fedora]{.tag} [python]{.tag} [nose]{.tag} [unittest]{.tag} [ovirt]{.tag} [node]{.tag} :::