In this post I'll show a simple replacement for Lux that only uses standard WiX markup.
First lets summarize the operational concept of Lux tests:
- Immediate custom actions set properties
- Deferred custom actions parse their CustomActionData properties and modify the system accordingly
- Lux tests properties alone, leaving deferred custom actions for other testing methods.
An example to a basic Lux test - taken from the extension's manual - looks like this:
This markup tests that a property named
<Fragment> <lux:UnitTest CustomAction="TestCustomActionSimple" Property="SIMPLE" Value="[INSTALLFOLDER]" Operator="equal" /> </Fragment>
SIMPLE equals INSTALLFOLDER property.
One can replace it with this markup, which makes no use of Lux:
<?ifdef UNIT_TEST ?>
TestCustomActionSimple" Error="10000" Execute="immediate" Return="check" />
<CustomActionRef Id="WixExitEarlyWithSuccess" />
<InstallExecuteSequence> <!-- Error if conditions show failure. --> <Custom Action="
INSTALLFOLDER) </Custom> <!-- Terminate Successfully if the test passes --> <Custom Action="
TestCustomActionSimple" /> </InstallExecuteSequence>
This markup defines an error custom action that will be executed if SIMPLE doesn't equal INSTALLFOLDER. If this condition fails (meaning SIMPLE equals INSTALLFOLDER) then the installation will terminate successfully by executing WixExitEarlyWithSuccess.
Lux defines few more test operators, these however are just shims for Windows Installer conditional operators.
Another major drawback of Lux is in its replacement of Product element: Lux replaces the Product element, ignoring anything within it. That means you have to re-organize your markup to be able to test it.
With the alternative markup I presented you don't need to change or re-organize any markup for unit tests to run.
To summarize Lux pitfalls:
- Limited scope - Lux only tests property values
- Lux doesn't check any installation flows
- Product element is ignored altogether.