I’m currently spending a lot of time working with custom actions, removing them where I can and improving them where they’re still necessary. The biggest change I’m making is to make the custom actions data driven using the immediate/deferred/rollback custom action triad. One of the advantages in doing so is that I can use Lux to help test my work. One of the advantages of that is that real-world experience is the best way to improve tools.
One of the challenges of developing data-driven custom actions is testing all the combinations of state that affect the custom action data immediate custom actions pass to deferred and rollback custom actions. Because Lux test packages don’t modify the machine, testing the full set of possible states is difficult. Providing known state is a strength of traditional unit-testing techniques, however; if your custom action code is well factored, it should be a simple task to provide a test double that arranges hard-coded state information that you can then test against.
Naturally, I wanted to figure out how I could provide the best of both worlds in Lux. Here’s what I came up with: test mutations. From the doc:
Test mutations let you author unit tests with different expected results. The mutation id is passed as the value of the WIXLUX_RUNNING_MUTATION property. Your custom action, typically in an ‘#ifdef DEBUG’ block, retrieves the WIXLUX_RUNNING_MUTATION property and mock different behavior based on the mutation. To author test mutations, use the Mutation element with UnitTest elements as children. For example:
<lux:Mutation Id="SimulateDiskFull">
<lux:UnitTest … />
</lux:Mutation>Nit runs the test package once for each mutation, setting the WIXLUX_RUNNING_MUTATION property to one mutation id at a time. Tests that aren’t children of a mutation are run every time.
Test mutations are a fairly simple change but one I hope simplifies combining traditional unit-testing techniques with declarative assertions.
Lux’s test mutations will ship in the next weekly release of WiX.
