Testing - test-containing assembly vs. add-in or workbook under test

No se nombran archivos del repositorio, puntos de entrada ni pruebas existentes; empieza por localizar la implementación de pruebas de Excel-DNA y su integración con xUnit runner. Define qué se necesita para asociar y cargar un complemento o un libro, y verifica el diseño frente a los escenarios descritos de pruebas de integración de VBA, .xll binario, .xlam y libros.

Normally the test assembly would have a reference to the assembly-under-test, and when running tests it will load and exercise the code inside the assembly-under-test.

For the Excel-DNA testing we might not have that direct link. We should e.g. cover that case where the add-in-under-test is actually written in VBA, or we only have a binary .xll of the add-in under test. Then the test code will consist of C# code that tests the add-in functions and other features by driving (through the COM object model) an instance of Excel where the add-in gets loaded, and then exercised.

I'm not sure what the best way is to associate the test code with a particular add-in for testing. There might be two cases,

• one where the add-in is part of the solution where the test code lives, and so can be referenced directly even if the code in the add-in is sometimes called directly while testing, and other times exercised through Excel.
• one cases where the add-in-under-test is declared only by a path or an add-in name, and then it is loaded or activated in Excel but not referenced directly by the assembly with the tests in. In this case we need some way in the test code to declare what add-in or other workbook(s) is required to be loaded in Excel before the tests execute. There's a question here of where to find these files too, maybe in paths relative to . . . somewhere? . . .

So one scenario I'd like to cover with the Excel-DNA testing is to create integration tests for VBA code (in an .xlam add-in or just behind a workbook) as well as tests for workbooks without any code. The tests are written in C# / VB.NET and run with any xUnit runner. So beyond the loading and running environment, we might imagine some helpers classes that make it easier to set code or formulas inside a workbook, let it calculate and then check results.
That idea is somewhat similar to what the XlWings guy discusses here: https://www.xlwings.org/blog/unittests-for-microsoft-excel