Crossposting from IdeSeg.com

Testeo unitario para SharePoint: La importancia de llamarse "Test"

csegura — Tue, 02 Dec 2008 03:34:49 GMT

Testing es algo que todos los desarrolladores deberíamos hacer, y muy pocos hacen. Por no decir “Testing intensivo y consecuente”, pues los números se reducen a prácticamente cero... si le da curiosidad, revise las estadísticas mostradas en:

Especialmente el segundo vinculo es interesante, aunque por experiencia propia me arriesgaría a decir que los porcentajes de aplicación de testeo son mucho, mucho mas bajos.

Siendo sincero, escribir software es una de las cosas más divertidas para hacer en el mundo (lo digo por deformación profesional, probablemente), pero hacer pruebas para ese mismo software es una de las más aburridas. Y en algunos casos, es simplemente imposible, como lo es hacer pruebas para SharePoint.

Pero para comenzar por el principio, hay que hablar algo sobre testing en general.

El mundo del testing es amplio y ajeno: hay tantos tipos de testeo como tipos de desarrolladores... pero mirándolo desde una perspectiva global, podemos decir que hay:

- “Unit Test” (Prueba unitaria) – verifica que las unidades individuales de código fuente funcionan como se espera. Normalmente la unidad de código más pequeña es una función, método o propiedad.
- “Regression Test” (Pruebas de regresión) – Cuando se modifica algo que ya ha sido probado que funciona (con el Unit Test), es necesario garantizar que sigue funcionando apropiadamente después de algún tiempo: este es el trabajo de Regression Test
- “Integration Test” (Pruebas de Integración) – Cuando todas las unidades (que ya han sido probadas con Unit y Regression Test) se unen para trabajar conjuntamente, es necesario garantizar que todas funcionen como una unidad apropiadamente. Este es el trabajo del Integration Test
- “System Integration Test” (Pruebas de Integración de sistemas) – puede ser visto como una ampliación del anterior: este test garantiza que nuestro sistema (que ya ha sido probado con Unit, Regression e Integration Tests) puede funcionar con otros sistemas externos apropiadamente

En cuanto a metodologías, mis dos hermanas sicólogas me enseñaron que hay tres tipos de pruebas: Black Box, White Box y Grey Box testing (el modelo ha sido tomado “prestado” de la psicología).

- “Black Box Testing” – la prueba no sabe nada sobre cómo funciona internamente el sistema a probar... solamente que si se le entregan algunos parámetros de entrada, deben salir algunos resultados. Black Box Testing le entrega parámetros a una función (correctos e incorrectos) y observa los resultados que la función devuelve
- “White Box Testing” – por el contrario, la prueba conoce perfectamente el funcionamiento interno del sistema a probar, y crea las pruebas basado en el.
- “Grey Box Testing” – ya se imaginaran lo que es, una mezcla de los dos.

Finalmente, es necesario hablar de algo que está de moda, “Test-driven development” (TDD). Esta es una técnica de programación basada en escenarios de prueba o de funcionamiento (Test o User Cases), bastante ligada a metodologías de desarrollo como Agiles, que indica que primero hay que hacer el diseño del software (sus clases, métodos, propiedades y eventos), luego generar las definiciones (el “esqueleto” del código), luego crear los métodos de prueba ANTES que el código mismo, y finalmente, crear el código para rellenar el esqueleto.

Bien, esto es más o menos la parte teórica. Como los desarrolladores de código que somos, ¿Qué es lo importante de todo esto?

Primero que todo, y antes que nada, Unit Test. Unit Test me permite dormir tranquilo, pues me asegura que mi código funciona correctamente y seguirá funcionando después de que lo he modificado (¿se puede usar Unit Test como Regression Test? Esta es una discusión bizantina a la que nunca nadie llega a una conclusión, algo por el estilo a que es mejor CSharp o Visual Basic, o Windows o Linux. Vea por la ejemplo la discusión que surgió en el ultimo PDC al respecto en http://channel9.msdn.com/pdc2008/TL61/).
Como segunda medida, si se está usando (o se quiere usar) TDD, la decisión de usar Black o White Test es importante... o, mejor dicho, si se quiere usar TDD, hay que usar Black Box Testing. Punto. O hay que iniciar una nueva discusión bizantina sobre si es posible iniciar el desarrollo en Black Box y luego continuarlo en White Box, lo que lleva al modelo de Grey Box...

Noten que hasta ahora he intentado no tomar partido por ninguno de los puntos mencionados. Todo porque mi punto es SharePoint, no discusiones teológicas sobre cómo, cuando y donde hacer testeo de software. Pero llegamos a la parte interesante: SharePoint.

Cuando se trata de crear Testeo Unitario para software creado por uno mismo, es decir, en donde se tiene el código fuente, construir las clases de prueba es largo y tedioso, pero es posible de hacer con las herramientas estándar para el efecto (como las que tiene Visual Studio mismo, por ejemplo). Cuando lo que se desea es testear código que utiliza el Modelo de Objetos de otro programa, como ocurre cuando se escribe software para SharePoint o cualquier otro servidor (SQL, Exchange, BizTalk, etc), es necesario “hacerle creer” a nuestro código que esta interactuando con el servidor, pero sin que lo haga en realidad, porque no se desean tener dependencias con él.

Imagínese una situación no tan hipotética: se crea un método que comprueba los derechos de una Librería de SharePoint; si se utiliza una instalación real de SharePoint para hacer las pruebas, es necesario mantener esa configuración por todo el tiempo del desarrollo y mas allá para garantizar que los resultados de las pruebas sean consistentes en el tiempo. Peor aún, todos los desarrolladores del grupo tienen que disponer de la misma instalación para que sus pruebas también sean consistentes entre desarrolladores. Esto es prácticamente imposible de conseguir y, además, muy engorroso. Para solucionar el problema existen diferentes tipos de herramientas que “falsifican” el Modelo de Objetos del servidor (Mockers, Stubbers, etc)

Como ya hemos dicho varias veces Carlos y yo, el problema con SharePoint y Unit Test es que el Modelo de Objetos de SharePoint tiene muchas clases selladas o sin constructor público. Este ha sido el gran problema hasta ahora para poder usar Mockers y Stubbers, pues ellos no saben qué hacer con un objeto sellado o sin constructor público. El posting “Testeo Unitario para SharePoint: acercándose a la respuesta definitiva – parte 1” que escribimos anteriormente comenzó a mostrar cómo se puede iniciar el testeo unitario para SharePoint usando la última versión de TypeMock. Las próximas partes continuaran con la parte práctica de la creación y codificación de las clases de prueba. Pero en esta segunda parte se trata de discutir la importancia de Unit Test, Regression Test, Black y White Box Testing y TDD.

Uno de las características más importantes de TypeMock es la relación intrínseca entre el código de trabajo y el código de testeo, es decir, el fabricante ha escogido por un modelo de “White Box Testing”. Veamos un ejemplo el ejemplo de una función que simplemente imprime los elementos de una Lista de SharePoint:

Código de trabajo:

        public void GetCollection01()
        {
            SPSite mySite = new SPSite("http://wsses");

            using (SPWeb myWeb = mySite.OpenWeb())
            {
                foreach (SPList myList in myWeb.Lists)
                {
                    foreach (SPItem myItem in myList.Items)
                    {
                        Console.WriteLine(mySite.Url + " - " + myWeb.Title + " - " + myList.Title + " - " + myItem.ID.ToString());
                    }
                }
            }
        }

Código de Prueba:

        [TestMethod()]
        public void GetCollection01Test()
        {
            SPWeb fakeWeb = Isolate.Fake.Instance<SPWeb>(Members.ReturnRecursiveFakes);
            SPList fakeList = Isolate.Fake.Instance<SPList>(Members.ReturnRecursiveFakes);
            SPItem fakeItem01 = Isolate.Fake.Instance<SPItem>(Members.ReturnRecursiveFakes);

            using (var recorder = RecorderManager.StartRecording())
            {
                SPSite myFakeSite = new SPSite("");
                recorder.ExpectAndReturn(myFakeSite.Url, "fakeSiteUrl").RepeatAlways(); 
                recorder.ExpectAndReturn(myFakeSite.OpenWeb(), fakeWeb);
            }

            Isolate.WhenCalled(() => fakeWeb.Title).WillReturn("fakeWeb");
            Isolate.WhenCalled(() => fakeWeb.Lists[2].Title).WillReturn("fakeList");
            Isolate.WhenCalled(() => fakeItem01.ID).WillReturn(1);

            Isolate.WhenCalled(() => fakeWeb.Lists[2].Items).WillReturnCollectionValuesOf(new List<SPItem>
               {
                    fakeItem01
               });

            Class1 target = new Class1();
            target.GetCollection01();

            var fakeItemList = fakeWeb.Lists[2].Items;

            foreach (SPItem item in fakeItemList)
            {
                Isolate.Verify.WasCalledWithAnyArguments(() => item.ID);
            }
        }

Para la prueba unitaria se está usando una combinación de “Natural Mocks” y el nuevo “AAA API” de TypeMocks. Observe un par de puntos específicos:

Cada objeto “real” necesita un objeto “mockeado”: myWeb -> fakeWeb, myList -> fakeList, etc
Para cinco líneas de código de trabajo se necesitan 17 líneas de código de prueba

Esto conlleva las siguientes consecuencias generales:

Para poder crear un objeto “fantasma” (un mock) que sustituya efectivamente al objeto “real” en la clase de trabajo, es necesario conocer explícitamente su construcción. Esto excluye directamente la utilización de TDD: código de prueba debe ser escrito antes del código de trabajo

Una consecuencia de esta consecuencia es que el código unitario deberá ser escrito por el desarrollador mismo que está escribiendo el código de trabajo: al final, es él/ella el que sabe que está haciendo. El peligro con esta construcción es que se van a escribir clases de prueba que casi siempre van a pasar el examen... voluntaria o involuntariamente, el desarrollador va a omitir las pruebas que tienen más posibilidades de fallar
Una segunda consecuencia de esta consecuencia es que el desarrollador probablemente utilizara más tiempo creando las clases de prueba que las clases de trabajo
Por la relación tan estrecha entre código de trabajo y de prueba, cuando se modifica algo en el código de trabajo, hay que modificar también el código de prueba. Es decir, Regression Test es imposible de realizar

El fabricante de TypeMocks está trabajando intensivamente para darle solución a estos problemas, y los primeros resultados van saliendo: ciertas partes del Framework de TypeMocks es capaz de crear mocks para trabajar con Black Box Testing, es decir, entregando un objeto “mockeado” al método de trabajo y revisando los resultados producidos, sin tener conocimientos de su funcionamiento interno.

En cualquier caso, la discusión de si testeo blanco o negro es el mejor, o si Test-Driven Development es realmente valido continuaran hasta el fin de los siglos. Lo importante para nosotros, los que estamos metidos en el lio de hacer que código funcione apropiadamente no son las discusiones teóricas, sino los Frameworks que nos permitan trabajar confortablemente. TypeMocks es hasta el momento lo que más se acerca a una solución viable para hacer testeo de código de SharePoint, así que vale más que la pena de darle por lo menos una mirada e intentar hacerlo funcionar.

Drupal and SharePoint. Dos formas de hacer una tortilla (charla en Navarra)

csegura — Mon, 01 Dec 2008 21:10:30 GMT

El próximo día 18 de diciembre tendremos en el Grupo de Usuarios de Navarra la charla (de los huevos y de los CKarlos), Karlos G. Liberal y un servidor hablaremos de algunas de las bondades de nuestras herramientas de trabajo (Drupal y SharePoint).

El magnifico cartel ha sido realizado por nuestros amigos de Sistema Formación.

La Agenda del evento es la siguiente:

La jornada será el jueves, 18 de diciembre
Hora de recepción: 18:00

Centros de Excelencia Software
Salón de actos
Plaza Cein, 1, Polígono Mocholi
Noáin Navarra 31110
España

AGENDA
18:30 - 19:30: Drupal and SharePoint. Dos formas de hacer una tortilla. Los CKarlos.
19:30 - 20:00: Celebración 2º aniversario de NavarraDotNet: zorionak zuri y tarta de cumpleaños
20:00 - 21:00: Drupal and SharePoint. Dos formas de hacer una tortilla. Los CKarlos
21:00 - ... : Cena!

Para apuntarse podéis hacerlos desde este enlace*
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032393640&Culture=es-ES

Cenando, Buenas Practicas, Historia de terror

csegura — Fri, 28 Nov 2008 20:36:06 GMT

Cenando

El otro día paso Unai por Pamplona y estuvimos cenando y departiendo sobre todas esas cosas frikis que nos gustan. Una suerte para los que habéis podido asistir a los cursos que ha impartido de Entity Framework y WCF.

Durante la cena, [[degustábamos unos “Penne Arrabiata” (no seáis mal pensados, que son macarrones con tomate un poco picante) y un “Ochoa Tempranillo” (recomendado)]], hablamos de; libros, de código, de más código, de bugs, de depuración, de tecnología, del bien y del mal (lo típico), no sé si ayer hablamos de sexo (no me acuerdo, pero con el frio que hacía es posible que no :-).

Bueno, la cosa es que le comenté algunas de las cositas del Api de SharePoint.

¿Buenas Prácticas?

Como ya he contado en alguna ocasión, las colecciones de SharePoint, son a la antigua usanza (Net 1.0), es decir que implementan IEnumerable, en una clase contenida, esto lo hacen en una clase abstracta SPBaseCollection del cual heredan el resto de colecciones de SP.

Bien, hasta el momento no hay mucho problema, es un tema de diseño, necesario para implementar las serializaciones de los objetos además de la persistencia que realiza sharepoint via COM.

Si realicemos una consulta usando SPQuery, (SPQuery nos permite recuperar elementos de una lista usando CAML, que es un meta-lenguaje basado en XML que tiene SharePoint para muchas cosas, entre ellas recuperar elementos de las listas)

<Where>
  <Geq>
    <FieldRef Name=”ID” />
    <Value Type=”Integer”>10</Value>
  </Geq>
</Where>

Nos devolverá todos los elementos de una lista donde el ID sea mayor que 10.

Para poder ejecutar una consulta CAML sobre una lista tenemos una clase llamada SPQuery a través de la cual montamos la consulta.

SPQuery query = new SPQuery
                {
                   Query = "CONSULTITA EN CAML"
                };

Para recuperar una colección de Items que cumplen esta consulta basta con indicar a la lista los items que queremos pasandole un SPQuery:

SPListItemCollection ítems = lista.GetItems(query);

Bien, como muchos ya sabéis que no es muy buena práctica devolver null, para no tener que comprobar si ítems es null antes de acceder, de modo que lo correcto es devolver una colección vacía (en este caso, como veremos luego tiene otro fundamento).

GetItems internamente nos devuelve una nueva colección

public SPListItemCollection GetItems(SPQuery query)
{
    return new SPListItemCollection(this, query);
}

Pero qué pasa si la consulta está mal formada ó es incompleta. Lo que cabe de esperar es:

1.- Que nos devuelva una excepción en el momento de crear SPQuery (cosa que no hace)
2.- Que nos ofrezca una propiedad o algo para comprobar si la consulta es correcta (cosa que no hace)
3.- Que nos devuelva una colección vacía (cosa que hace peligrosamente a medias)

¿Por qué lo hace a medias? Porque aparentemente nos devuelve una colección vacía, es decir si la consulta está mal, ítems no es null. Pero OJO no es una colección valida.

SPQuery query = new SPQuery
                {
                        Query = "MI mala CAML Query"
                };

SPListItemCollection items = list.GetItems(query);

if (items!= null)
{
    Debug.WriteLine("Soy una colección no nula. Parece que valgo...");
    
    // Ahora reviento
    foreach (SPListItem item in items)
    {
    }
}

Las colecciones de este tipo en SharePoint, son de carga retardada de modo que la colección se carga cuando realmente vamos a usarla (Lazy-Load / Proxy), en ese momento se hace una petición SPRequest que es al que se encarga de recuperar el contenido y obtener la colección de elementos. (fundamento)

En ese momento se usa la consulta SPQuery que le hemos pasado para recuperar los datos, y al tratar de cargarla, como la consulta está mal formada, da una excepción (no advertida ni documentada), y la colección sigue siendo una colección hasta que usemos alguna de sus propiedades o tratemos de recorrerla. Es decir no es una colección vacia, si no una colección donde todo se ha quedado mal inicializado si intentas un items.Count antes de recorrer la colección tambien dará una excepción ya esta va a producirse de igual manera al cargar los datos.

De modo que la buena práctica se convierte en mala práctica ya que se pasa de hacer una comprobación de null antes, a tener que hacer un Try/Catch en el momento de recorrer la colección (como decimos por aquí, cojonudo).

Como alternativa, se puede implementar un método por ejemplo, vía extensión; para comprobar que la consulta es valida y en caso de no serla que nos devuelva una colección bien formada cuando menos. Otra alternativa podría ser otro método como EnsureCollection, a través del cual podamos recuperar la excepción si nos interesa comunicar que la consulta esta mál formada.

La cosa sería algo así:

public static SPListItemCollection TryGetItems(this SPList list, SPQuery query)
{
    SPListItemCollection items; 

    try
    {
        items = list.GetItems(query);
        int count = items.Count;
    }
    catch(SPException ex)
    {
        query.Query = string.Empty;
        items = list.GetItems(query);                
    }
    
    return items;
}

JA, pero ahí no termina la cosa … los señores de SharePoint son unos fenómenos optimizando y lo que hacen SPQuery internamente es generar una Vista (propiedad ViewXml de SPQuery), para optimizar el rendimiento, esta vista en Xml, se genera reuniendo todas las propiedades de SPQuery, y se genera siempre y cuando no se ha generado antes (optimización)

De modo, que si cambiamos la propiedad Query de SPQuery, la consulta interna ViewXml no cambia (ya se genero antes), manteniendo la última consulta generada, para lo cual debemos limpiar ViewXml.

query.Query = string.Empty;
query.ViewXml = string.Empty;
items = list.GetItems(query);

¿Por qué que les habría costado implementar un flag de suciedad y reconstruir la ViewXml cada vez que el objeto este sucio? ¿por qué no documentarlo?

En fin, la cena estuvo genial.

He leido "Code Clean", de Robert C. Martin

csegura — Tue, 18 Nov 2008 04:16:37 GMT

He terminado de leer el último libro de Robert C. Martin, Clean Code.

De Robert, había leído otros dos libros, “UML para programadores Java”, una guía práctica y sin rodeos de cómo usar UML en proyectos reales; y cuando digo práctica es que no se anda por las ramas y en ocasiones en un tono incluso “irónico” explica perfectamente cómo debemos usar UML.

El otro libro es Agile Principles, Patterns, and Practices in C# (Robert C. Martin Series), que puedo decir de este libro ampliamente comentado, uno de los que se deben tener. (Ya sabéis que se lo recomiendo a todo el mundo)

Bueno, de modo que “Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series) ” tenía todos los boletos de ser un gran libro. No ha defraudado en absoluto.

Apenas empezarlo, en la introducción ya me había pillado. (Ilstración de la introducción)

El libro explica cómo escribir buen código, código legible y eficiente. Los ejemplos son en Java, pero tener en cuenta que estamos hablando de cómo escribir buen código, habla del significado de los nombres, de las funciones, de los argumentos, del tipo de retorno, de cómo comentamos el código, de las reglas de formato, de objetos y estructuras de datos, de la gestión de errores, de las pruebas unitarias, del diseño simple, de sistemas, de concurrencia, de refinamiento, de olores y heurística. Habla de estilo, de buen estilo.

De veras, me ha parecido un libro impresionante, con unos ejemplos claros, con un estilo cuidado y detallado, sin dejar cosas fuera, insistiendo en las cosas importantes (esto a mí me gusta, así entran mejor las cosas)

Vamos un libro que entra de lleno en mi TOPTEN.

Resumen del DevCamp en NavarraDotNet

csegura — Mon, 17 Nov 2008 18:05:40 GMT

Un "poquito" tarde (y con mucha ayudita) os dejo el resumen con todos los detalles del DevCamp en el blog de NavarraDotNet

http://www.navarradotnet.com/post/navarradotnet-en-el-7bdev_camp7d.aspx

Y la información sobre el próximo evento el University Tour

http://www.navarradotnet.com/post/el-University-Tour-viene-a-la-UPNA.aspx

(Para los que no lo sepan, en la Upna se esta organizando un DotNetClub)

http://www.navarradotnet.com/post/se-esta-cociendo-un-DotNetClub-en-la-UPNA!!.aspx

y como no, siempre vuelve a casa por navidad ... (como el turron)

http://www.navarradotnet.com/post/Chema-Alonso-en-CuatroVientos-Una-sesion-dirigida-a-estudiantes.aspx

Toda la información sobre el paso del Guille por Pamplona (Gracias Guille)

http://www.navarradotnet.com/post/gracias-Guille.aspx

EL GIRAO DEL GUILL-E EN PAMPLONA

csegura — Sun, 05 Oct 2008 15:56:37 GMT

El Community Tour 2008 del Guill-e consiste en que, después de varios meses de un arduo trabajo de coordinación, nos hemos organizado muchos grupos de usuario (los de Málaga, Madrid, Valencia, Reus, Barcelona, Igualada, Vic, Andorra, Pamplona, Murcia, Albacete, Huelva, Bilbao, La Coruña, Mallorca, Cantabria, Valladolid y también SecondNug) y hemos quedado con el amigo Guillermo Son para que haga una pequeña ;) gira y venga a hacernos una visita a todos, a enseñarnos las cosas nuevas que ha aprendido del lenguaje ese en el que no se pierde el tiempo poniendo puntos y comas (expresión suya).

Guille nos ha contando que está intentando echar un cable a un chaval que está en una situación muy apurada y hemos decidido ayudarle también así que la gira es solidaria con Juanma. Para animar a la colaboración se sortearán durante la gira un montón de regalos:

1 Visual Studio 2008 Profesional
2 suscripciones MSDN Premium con Visual Studio Team System 2008 Team Suite (valorada cada una en más de 5.000 Euros).
10 Packs de Productividad que incluye Resharper y dotTrace
16 libros de Novedades de Visual Basic 9.0 (uno para cada evento)
16 libros de Novedades de C# 3.0 (uno para cada evento)
65 Suscripciones a la revista dotNetManía (48 de 3 meses y 16 de un año)

En Pamplona, además tenemos la suerte de volver a contar con David Salgado, que hará de telonero de lujo y nos hablará de opciones para del desarrollo de un sitio web .NET.

Os esperamos el día 15 de octubre de 16:30 a 21:00 en el salón de actos de los Centros de Excelencia Software, polígono industrial Elorz-Mocholí en Noain.

La agenda:

16:30-17:00: Bienvenida y registro. Reunión del grupo de usuarios NavarraDotNet. Orden del día: nuestros saraos

17:00-18:30: Opciones para el desarrollo de un sitio web .NET, David Salgado

Con la llegada del SP1 de .net 3.5, se abre el abanico de opciones a valorar a la hora de desarrollar un sitio web. Hasta ahora contábamos con ASP.NET y algunas pinceladas de ASP.NET AJAX. A dia de hoy contamos además con una nueva versión de Visual Studio, ASP.NET MVC, ASP.NET Dynamic Data, ASP.NET Dynamic Services, un soporte mejorado de ASP.NET AJAX e Internet Explorer 8 como navegador. Descúbrelos, resuelve tus dudas y decide qué es lo más adecuado para tus desarrollos.

18:30- 19:00: Merienda patrocinada por el CES

19:00 -21:00: El Guille con la comunidad, Guillermo Som

Novedades y ejemplos prácticos de Visual Basic 9, ejemplos prácticos de uso de LINQ. Aprovecha la primera visita que hace elGuille a Pamplona: ¡pregúntale al Guille!

Como siempre, la entrada es gratuita previo registro en:

Inscripción a través de Microsoft

Inscripción a través de CEIN

Y tenéis más información y el fantástico cartel que ha hecho nuestro Sergio Jimenez en http://www.navarradotnet.com/post/el-Guille-en-Pamplona!!!.aspx.

(by: Elena)

Programando a cuatro manos: Unit Test para SharePoint

csegura — Mon, 22 Sep 2008 02:36:02 GMT

Aquí continúa el drama de Unit Test para SharePoint. Esta vez hemos reunido esfuerzos entre nosotros, Carlos Segura (http://www.ideseg.com ) y Gustavo Velez (http://www.gavd.net ), para intentar sacar algo en claro. Programadores del mundo de SharePoint, uníos! ...

Unit Test, SharePoint y que es lo importante:

Testeo Unitario es una técnica de programación que permite asegurar que lo que se ha programado hoy cumple las condiciones exigidas, y que las seguirá cumpliendo en el futuro, cuando se hagan modificaciones en el código fuente. Existe numerosa información al respecto, tanto en libros de texto como en internet, así que no repetiremos las bases de la técnica; en resumen, es deseable que se
cumplan algunas condiciones:

- El código de Pruebas Unitarias debe ser independiente de cualquier FrameWork que se esté utilizando para garantizar que no hay dependencias, es decir, circunstancias que no se puedan repetir en el futuro. En nuestro caso, no se desea tener que utilizar una instancia de SharePoint para ejecutar el testeo, pues es prácticamente imposible crear dentro de algunos meses/años un sistema de SharePoint que sea exactamente igual al utilizado originalmente

- El código de Pruebas debe ser fácil y rápido de escribir. El (valioso) tiempo de programación se debe utilizar para programar la funcionalidad, no para programar el sistema de pruebas

- El código de prueba tiene que ser igual para todos los desarrolladores en el equipo de desarrollo. Esto tiene que ver con el primer punto: si no existen dependencias (configuraciones, por ejemplo) con el FrameWork utilizado, no hay riesgos de que dos desarrolladores obtengan diferentes resultados. O que el sistema de compilación automática produzca resultados impredecibles (Night Build, Continuous Build, Regretion e Integration Test)

Unit Test es comúnmente utilizado en desarrollo de software, y existen varias herramientas que lo facilitan. Visual Studio (versión profesional y superior) provee todas las herramientas necesarias para generar Unit Test con un clic; si no se dispone de una de estas versiones de Visual Studio, existen herramientas gratuitas que pueden hacer el mismo trabajo (NUnit, http://www.nunit.org/, xUnit, http://www.codeplex.com/xunit y TestDriven, http://www.testdriven.net/ por ejemplo).

Cuando se desean hacer Pruebas Unitarias para SharePoint es necesario utilizar técnicas suplementarias que permitan crear “imágenes fantasmas” de sus clases. Esto se puede conseguir de diferentes formas, por medio de Mocking o Stubbing, por ejemplo

• http://geeks.ms/blogs/gvelez/archive/2007/08/04/mocks-mocking-mockers-y-sharepoint.aspx
• http://geeks.ms/blogs/gvelez/archive/2007/08/12/stubs-stubbing-stubbers-y-sharepoint.aspx
• http://www.ideseg.com/SharePointPruebasUnitarias1.aspx

Otras técnicas, como la utilización de Plantillas o Copias de Seguridad son utilizables, pero no cumplen las condiciones ideales indicadas al principio.

Mocking es una técnica que permite crear objetos “falsos” de un determinado FrameWork, y luego “convencer” al código a probar que tiene que usar los objetos falsos, y no los que obtendrán del FrameWork en su trabajo real. Esta técnica permite cumplir todas las condiciones indicadas. Desafortunadamente, por la forma de programación de SharePoint no es posible usar Mockers tradicionales.

La nueva versión de TypeMock (versión 5.0, http://www.typemock.com ) permite crear objetos mock que funcionan bajo estas condiciones, haciéndolo ideal para crear Unit Test para SharePoint. Desafortunadamente, TypeMock es una herramienta comercial, pero se puede bajar del sitio indicado una versión de prueba completamente funcional por 30 días.

Otra de las motivaciones para usar TypeMock, es que el equipo de SharePoint Guidance está usando TypeMock en sus ejemplos; el porqué es simple, a pesar de que existen otras alternativas en el mercado, y algunas de uso libre, ninguna de ellas es capaz de mockear clases selladas o clases que no tienen un constructor público. La API de SharePoint cuenta con innumerables clases y una gran parte de ellas están selladas y carecen de constructores públicos por lo que TypeMock es la única alternativa por el momento.

Mockeando a SharePoint

1 - El caso más sencillo: mockear a SPSIte y SPWeb. El método a probar tiene la siguiente forma:

       public static string TestMock_01()
       {
            String strReturn = String.Empty;

            try
            {
                using(SPSite mySite = new SPSite("http://MiServidor"))
                {
                    using(SPWeb myWeb = mySite.OpenWeb())
                    {
                        strReturn = myWeb.MasterUrl;
                    }
                }
            }
            catch (System.Exception ex)
            {
                strReturn = ex.ToString();
            }

            return strReturn;
        }

Y el método de Pruebas Unitarias con TypeMock seria:

        public void TestMethod1()
        {
            using (RecordExpectations recorder = RecorderManager.StartRecording())
            {
                SPSite mySiteMocked = new SPSite("");
                SPWeb myWebMocked = RecorderManager.CreateMockedObject<SPWeb>();
                recorder.ExpectAndReturn(mySiteMocked.OpenWeb(), myWebMocked);
                recorder.ExpectAndReturn(myWebMocked.MasterUrl, "abcd.master").RepeatAlways();
            }

            string expected = "abcd.master";
            string actual;
            actual = Program.TestMock_01();
            Assert.AreEqual(expected, actual);
        }

Bajo el estamento “using” se crean objetos SPSite y SPWeb “falsos”. Todos los objetos creados bajo el “recorder” serán después utilizados como objetos de trabajo en la función a testear, en lugar de los objetos “reales” obtenidos del FrameWork de SharePoint. Esto permite garantizar que en el ejemplo, no importa qué tipo de configuración tenga la instalación actual de SharePoint, siempre se le va a “hacer creer” al método a testear que la página maestra del Web se llama “abcd.master”.

Luego de crear los objetos mockeados, se inician las variables a esperar (expected), se ejecuta el método a probar y el resultado se compara con lo esperado.

2 - Yendo algo más lejos: mockeando colecciones. Cuando se desea utilizar la misma sintaxis para crear objetos mockeados de colecciones se encuentran diferentes dificultades. En las colecciones de SharePoint se ha mantenido el diseño existente en versiones anteriores por lo que funcionan como lo hacían en Net 1.1: una clase que implementa IEnumerable y una clase anidada que implementa IEnumerator; para poder recorrer colecciones de objetos mockeados se debe reproducir este comportamiento y lo que a priori puede parecer fácil en realidad no lo es…

En primer lugar se debe mantener una colección de objetos paralela a través del cual podamos devolver un enumerador; se puede ver un ejemplo de esta técnica en (http://dotnetforum.dk/blogs/mac/archive/2007/12/21/first-steps-with-typemock-and-the-sharepoint-api.aspx), lo cual nos obliga en cierta manera a crear métodos para reproducir las colecciones de objetos de SharePoint.

En parte motivados por esto y por la necesidad de poder realizar los tests de la manera más sencilla posible hemos creado un conjunto de clases envoltorio que nos permitirán extender los objetos a mockear de SharePoint de una manera más elegante.

Por ejemplo, para el siguiente método a probar, en el que se necesita recorrer la colección de Listas en el Web de más alto nivel:

        public static string TestMock_02()

            string strReturn = String.Empty;

try

                using (SPSite mySite = new SPSite("http://MiServidor"))

                    using (SPWeb myWeb = mySite.OpenWeb())

                        int intTeller = 0;

                        foreach (SPList oneList in myWeb.Lists)

                            Debug.WriteLine(oneList.Title);

                            intTeller++;

                        strReturn = intTeller.ToString();

            catch (Exception ex)

                strReturn = ex.ToString();

            return strReturn;

Se puede utilizar un método de prueba con la siguiente sintaxis:

        [TestMethod]

        public void TestMethod2()

            MockSPSite mockSite = new MockSPSite("TestSite");          // 1

            MockSPWeb mockWeb = new MockSPWeb("TestWeb");  // 2

            MockSPList mockList0 = new MockSPList("MyList0");         // 3

            MockSPList mockList1 = new MockSPList("MyList1");

            MockSPList mockList2 = new MockSPList("MyList2");

            mockWeb.Lists = new MockSPListCollection(new[]             // 4

                   mockList0,

                   mockList1,

                   mockList2

});

            mockSite.ExpectGetAlways("RootWeb", mockWeb.GetInstance());  //5

            SPWeb WebMocked = mockWeb.GetInstance();    // 6

            using (RecordExpectations recorder = RecorderManager.StartRecording())    // 7

                SPSite SiteMocked = new SPSite("");    // 8

                recorder.ExpectAndReturn(SiteMocked.OpenWeb(), WebMocked);    // 9

            string expected = "3";    // 10

            string actual;

            actual = Program.TestMock_02();

            Assert.AreEqual(expected, actual);

Aquí se pueden distinguir tres zonas con código:

-   En la primera parte, líneas 1 a 7 se crean todos los objetos “falsos” necesarios. Líneas 1 y 2 crean objetos del tipo SPSite y SPWeb. Las líneas bajo el numero 3 crean tres Listas mockeadas y en la línea 4 se agregan las Listas a la Colección de Listas del objeto SPWeb mockeado. En la línea 5 se agrega a su vez el objeto SPWeb como la Web de nivel superior del objeto SPSite mockeado y finalmente, en la línea 6 se crea un objeto del tipo SPWeb nuevo basado en el objeto SPWeb mockeado. Esto es necesario para el código en la segunda zona, que no permite utilizar objetos mockeados directamente

-   En la segunda zona, líneas 7 a 9, se crean los objetos que se le van a entregar a la clase a testear por medio de un “recorder” de TypeMock. En la línea 8 se crea un objeto SPSite que va a substituir el SPSite en la clase a testear, y en la línea 9 se le asigna el valor del objeto SPWeb mockeado con las Listas creadas en la primera parte.

-   La tercera zona, desde la línea 10, incluyen el código para los valores esperados y los valores que regresan del método a testear y los comparan en la aserción.
La primera parte del código utiliza las clases envoltorio comentadas anteriormente (MockSPSite, MockSPWeb, etc). Estas clases tienen la forma:

namespace SPTypeMock.Core

    public class MockSPSite : MockSP<SPSite>

        public MockSPSite(string url) : base(true)

            if (string.IsNullOrEmpty(url))

                throw new ArgumentNullException("url");

            Mock.ExpectGetAlways("Url", url);

Estas clases sirven para simplificar la creación de los objetos mockeados, y no son más que herencias de tipos definidos (SPSite en este caso), con algunos constructores específicos y métodos para conectar sus colecciones de objetos. Las clases de envoltura permiten reutilizar el código una y otra vez, sin que la escritura de las pruebas signifique el tener que escribir mas código que el código a testear (una de las condiciones señaladas al principio).

Todas estas clases se encuentran en la biblioteca SPTypeMock que podéis encontrar en CodePlex

SPTypeMock usa dos clases, la primera es MockSP<T> que es una clase abstracta desde la cual mockearemos los objetos de SharePoint, la única peculiaridad de esta clase está en el constructor, que tiene un parámetro bolean, que se encarga de añadir la propiedad ID de la clase; las clases de SharePoint tienen un ID, en la mayoría de ellas es un Guid, pero en otras como SPListItem es un int.

La propiedad Mock de esta clase nos da acceso al objeto mock que se encuentra en el interior, debemos usar esta propiedad para establecer las expectativas.

El método GetInstance, se encarga de devolvernos una instancia real del objeto mockeado.

La segunda clase es MockSPCollection<TCollection,TItem> que es otra clase abstracta desde la cual heredaremos las colecciones de SharePoint. MockSPCollection, hereda a su vez de List<TItem> de modo que así conseguimos tener la colección paralela necesaria para trabajar con las colecciones de SharePoint.

Disponemos de dos constructores uno que se encargará de crear colecciones vacías y otro al que podemos pasarle una lista de elementos que formarán parte de la colección. Al obtener una instancia de la colección por medio de GetInstance(), establecemos que la interfaz IEnumerable será obtenida de la lista; también aquí nos encargamos de mockear el index por defecto que será a través de un int.

Si las colecciones que deseamos usar tienen otros índices como SPListCollection, que tiene un índice por título de la lista y otro por Guid, podemos sobrescribir el método CustomIndex en las clases heredadas implementando dicha funcionalidad.

No todo es perfecto...

No todo ha sido solucionado, algunos problemas quedan aún por resolver:

-   La instalación de TypeMock no permite seleccionar un directorio de instalación, lo que limita la utilización de programas de compilación automático, como Cruise Control por ejemplo

-   Los objetos mockeados creados en las dos primeras zonas de la clase de prueba son creados en un Thread diferente al utilizado por SharePoint al crear los objetos en el método a testear. Esto tiene como consecuencia que si se desea destruir los objetos al final del método a probar (por medio de un “using” para el SPSite y/o el SPWeb, o por medio de un “Dispose()” al final del método), SharePoint producirá un error en sus logs indicando “ERROR: request not found in the TrackedRequests. We might be creating and closing webs on different threads”

-   Es necesario crear aun muchas más clases de envoltorio

Triste perdida para la comunidad de SharePoint

csegura — Fri, 05 Sep 2008 16:29:29 GMT

Normal 0 21 false false false ES X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Tabla normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0cm; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

El pasado día 3, Patrick Tisseghem co-fundador de U2U, murió de una afección cardiaca. Desde aquí quiero enviar un cariñoso y fuerte abrazo a su familia y a la gente U2U.

Patrick ha sido una inspiración para muchos de nosotros y toda la comunidad de SharePoint, lamentamos esta gran pérdida.

Beginners Guide to TD WebPart Development

csegura — Fri, 29 Aug 2008 00:12:20 GMT

Hace algún tiempo hable de las pruebas unitarias para desarrolladores de SharePoint (y seguiremos hablando de ello)

SharePoint - Pruebas Unitarias (1)
SharePoint - Pruebas Unitarias (2)
SharePoint - Pruebas Unitarias (3)

Andrew Woodward, acaba de publicar un MUY interesante documento “Beginners Guide to Test Driven Web Part Development”, que os recomiendo. Se puede descargar desde su blog.

Tres libritos que se pueden descargar gratis sobre MOS

csegura — Tue, 26 Aug 2008 03:39:49 GMT

La buena noticia, son gratix la mala puede que hayaís leído parte o todo en, Office SharePoint Server technical library, a mi me gusta más el papel ....

Guía de configuración de MOSS para la gestión de contenidos empresariales y gestión de registros.

Records Management Guide for Microsoft Office SharePoint Server 2007

Planificación de la estructura de sitios web y entorno de publicación (interesante la parte de creación automática de de sitios web y aprobación para la publicación, ya sabeís que mi fuerte no es el CMS pero se me han ocurrido unas cositas interesantes)

Microsoft Office SharePoint Server Web Publishing and Planning Guide

Diseño y contruccion de sitios con MOSS

Design and build sites for Office SharePoint Server 2007

Saludetes ...

Tres libritos que se pueden descargar gratis sobre MOSS

csegura — Tue, 26 Aug 2008 03:39:49 GMT

Records Management Guide for Microsoft Office SharePoint Server 2007

Microsoft Office SharePoint Server Web Publishing and Planning Guide

Diseño y contruccion de sitios con MOSS

Design and build sites for Office SharePoint Server 2007

Saludetes ...

Online YACAMLQT, the SQL to CAML converter

csegura — Fri, 27 Jun 2008 22:53:53 GMT

Thanks to the guys from SPSProfessional, my small toy YACAMLQT, is ONLINE you can play with this in www.spsprofessional.com/sqlcaml.aspx

Enjoy...

NavarraDotNet - Sql Server 2005 Integration Services

csegura — Thu, 29 May 2008 14:32:48 GMT

Evento: “Sql Server 2005 Integration Services"

Día: 30 de mayo 2008, hora: 18:30-20:30
Lugar: Sistema Formacion. Plaza Pintor Paret, 1. 31008 Pamplona
Colaboran: Sistema Formación, Masbytes, navarraDotNet, MSDN

Ponente: Patxi Esteban. Biko2, navarraDotNet

Agenda:

18:30 - 19:00: Reunión de navarraDotNet. Orden del día: nuestros saraos
19:00 - 20:30: Sql Server 2005 Integration Services. Patxi Esteban.

Integración de datos de alto rendimiento con los paquetes ETL(extracción, transformación y carga), mucho más que una versión 2 de los DTS(Servicios de transformación de datos).

Entrada libre previo registro en:

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032376400&Culture=es-ES

Edit your SQL Server DataBase from INSIDE SharePoint

csegura — Sun, 11 May 2008 01:20:00 GMT

WOW. In only 4 minutes, connecting two webparts. You can download a public beta from www.spsprofessional.com

View Full Screen

The return of the RollUP

csegura — Mon, 05 May 2008 21:56:24 GMT

It returns, the best Roll Up of contents for Share Point, of the hand of SPSProfessional. Sure it sounds you a lot.

And besides now it does pretty graphics.

More information in www.spsprofessional.com