[wix-users] Unit Test Deferred Custom Actions

Jon Earle earlej at hotmail.com
Thu Mar 22 07:48:29 PDT 2018


Nir: Yes, you are technically correct.  However, if the goal is to prove the functionality and failure paths are correct, then running as admin permits that. Execution testing will quickly determine whether or not your permission level is adequate. As we install drivers, we require the installer to be run as admin.

I was trying to create a Log function, but I'm having trouble replacing the pointers in the object. Don't really want to add more logic to the code for logging, if I can avoid it (just another thing to test).

If I have the following CA:

        [CustomAction]
        public static ActionResult CreateDb(Session session)
        {
            session.Log("Begin CreateDb Custom Action");
            try
            {
                string svPath = Path.Combine(session.CustomActionData["INSTALLDIR"], DB_DIR);
                Directory.CreateDirectory(svPath);
                svPath = Path.Combine(svPath, DB_FILE);
                File.Open(svPath, FileMode.OpenOrCreate).Close();
            }
            catch (Exception ex)
            {
                session.Log("Failed to create " + svPath + " : " + ex.ToString());
                return ActionResult.Failure;
            }
            finally
            {
                session.Log("End CreateDb Custom Action");
            }
            return ActionResult.Success;
        }

It would be very helpful to simply mock up the Session object so that I can test the method as written, parsing the data and logging as before, except, logging now to a new method and not to the MSI method from the standard Session object.

Otherwise, I have to yank out the logic from the try{} block, add return paths for any data I wish sent back (for logging), yadda yadda, then test it all.  It just makes writing the CA's (with unit tests in mind), a _lot_ more difficult than it really needs to be.  Mocking Session solves all of it.

Jacob: I haven't wanted to mock anything other than Session.. not sure if there would be a need or what others might feel.

Cheers!
Jon
________________________________
From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of Nir Bar via wix-users <wix-users at lists.wixtoolset.org>
Sent: Wednesday, March 21, 2018 10:54 AM
To: WiX Toolset Users Mailing List
Cc: Nir Bar
Subject: Re: [wix-users] Unit Test Deferred Custom Actions

Since you already factored-out the execution logic from the Session parsing logic you can simply create a local Log() function that will dump log messages to Session.Log() or Console.WriteLine() as appropriate.

One thing to note however, is that unit-testing custom actions can't be complete without executing it in LocalSystem account (as opposed to an Administrator account).

I usually unit-test custom actions by developing a standalone package that only executes the custom action.
I suppress PublishXXX and RegisterXXX standard actions so the package just executes the custom actions without leaving any other trace on the machine.




--
Nir Bar, Independent WiX Expert. Creator of-
JetBA: WiX WPF Bootstrapper User Interface Framework

JetBA++: WiX Native Bootstrapper User Interface Framework




____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/


More information about the wix-users mailing list