Add support for unit testing in Excel-DNA

Currently it is not possible to unit test Excel add-ins built with Excel DNA, because pretty much all interactions one does with the Excel DNA framework requires calling methods in static classes, which in turn call Excel APIs/features and because these are static classes, it is not possible to mock these classes.

I’ve made a good process with my ExcelDna.Abstractions project which addresses many of these issues, but it is not ideal and it is harder to maintain as Excel DNA moves and new methods are added.

I’d like all static classes that relies on Excel functionality to be implemented as regular classes that also implement interfaces (so that we can depend on these interfaces instead, and be able to mock) and then mark the static classes Obsolete, to encourage devs to use the new regular classes/interfaces.

This issue is somewhat related to issue #20.

[augustoproiete]

Yep. Totally agree with keeping existing static classes for backward compatibility (although I’d advocate setting a date/version # to mark these as Obsolete to encourage devs to start moving away from the static classes).

Not sure I understood the last part though.

At the moment, my add-ins do have a lot of complexity exactly because Excel-DNA do not embrace unit testing (or DI for that matter #20), so we have to jump through hoops to be able to unit test our ViewModels, Controllers, etc. We end up having to create all these wrappers for any interaction with Excel-Dna.

The goal of this issue is exactly to remove the need for this extra complexity, so that add-ins can be simpler. Not add more complexity. What complexity do you see in the code snipped above (AddIn class)?

An external library would not have the opportunity to run before the IExcelAddIn.AutoOpen or before the constructor of an IRibbon, so I don’t see how would be possible to add proper support for unit testing via an external library without having Excel-DNA embrace the use of the interfaces - and stop relying on a concrete implementation.

---

When you say you’re not keen to support do you mean that:

a) Someone would have to take responsibility to implement this and support this code (which would have to be inside Excel-DNA for it to work)

or

b) You don’t want Excel-DNA to evolve in that direction at all, so no intention to merge a PR that enables such a thing

or

c) Something else

---

As I said before, I’m happy to volunteer for a). I really like the Excel-DNA project, and I’m keen to contribute more.

[augustoproiete]

@govert: Just to clarify, despite not being in your roadmap, would you be open to a PR that makes the necessary changes for this to become possible?

From the point of view of developer, it wouldn’t change much. Think something like this:

public class AddIn : IExcelAddIn
{
    public void AutoOpen(IExcelIntegration excelIntegration)
    {
        // << Insert code that I can unit test here >>

        excelIntegration.RegisterUnhandledExceptionHandler(ex => {
            // ...        
        });

        // << Insert code that I can unit test here >>
    }
}

As you can see, all the developer had to do, was ask the framework to provide an instance of ExcelIntegration in order to use (which of course would be a singleton).

This opens the door for mocking the methods in IExcelIntegration and therefore devs can unit test the whole AutoOpen method - and can even check if an exception handler has been registered or not (and fail the test if didn’t).