El Bruno

Buenas,

hace bastante tiempo comenté un truco la configuración necesaria para poder utilizar TFSBuild para ejecutar pruebas unitarias en proyectos del tipo AddIn de Outlook. Hoy, 2 años después mi recomendación sigue siendo la misma:

No incluyas lógica compleja en tu proyecto de AddIn. Separa la misma en proyectos separados y cada uno con su set de pruebas … etc. Vamos que sigue siendo SOLID al 100%.

Ahora bien, si por algún motivo extraño de la vida, te encuentras en un escenario donde las clases con la “lógica compleja” deben estar dentro del proyecto del AddIn y la prueba unitaria de las mismas es un tanto compleja (por ejemplo para AddIns de Office 2003 con Visual Studio 2008), pues existe un truco que no recomiendo, pero que cumple su objetivo.

Lo mejor es mostrarlo con un proyecto de ejemplo, como en la siguiente imagen donde podemos ver un proyecto de AddIn para Outlook con una clase llamada [GuidValidator] que obviamente nos permite validar un Guid.

Nota: pa los criticones, si no les gustan los nombres de las clases, pues … a leer otra cosa !!!

El código para validar el guid tampoco es que sea muy complicado:

   1: using System.Text.RegularExpressions;

   2:  

   3: namespace OutlookAddIn1

   4: {

   5:     class GuidValidator

   6:     {

   7:         public static bool Validate(string textToValidate)

   8:         {

   9:             var isGuid = new Regex(

  10:               @"^(\{){0,1}[0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{12}(\}){0,1}$", 

  11:               RegexOptions.Compiled);

  12:             return isGuid.IsMatch(textToValidate);

  13:         }

  14:     }

  15: }

Pero claro, probar unitariamente algo tan simple como una expresión regular utilizando todo el contexto de un AddIn de Outlook, es muy pesado. La solución nos la pueden dar los siguientes pasos.

1. Agregar un nuevo proyecto del tipo ClassLibrary a la solución. En mi caso lo llamaré [AddInToTest]

2. Eliminar la clase que viene por defecto en el proyecto.

3. En las propiedades del proyecto cambiar el namespace por defecto del proyecto ClassLibrary para que coincida con el namespace por defecto del proyecto del AddIn

4. Agregar como link la clase [GuidValidator] ubicada en el proyecto del AddIn

5. Agregar los tests unitarios de la clase [GuidValidator] en un proyecto de test separado

La estructura de la solución queda similar a la siguiente.

En la misma es posible ver que si bien la clase [GuidValidator] pertenece al proyecto [OutlookAddIn1], la misma se utiliza como archivo externo en el proyecto [AddInToTest] y se implementan las pruebas en el proyecto de test [AddIn.Tests].

El truco es bastante simple, poco elegante, pero funciona. Si quieres descargar el código de ejemplo para darle un vistazo lo puedes hacer desde aquí

http://cid-bef06dffdb192125.office.live.com/self.aspx/Code%20Samples/2011%2001%2004%20Hack%20to%20unit%20testing%20Outlook%20AddIns.zip

Saludos @ Home

El Bruno