[SharePoint 2013] Introducción a las pruebas unitarias

Si no estoy indicando ningún tabú, en SharePoint se pueden y es más se deben de hacer pruebas unitarias. Hay poco escrito sobre las pruebas unitarias en SharePoint (lo único que he leído fue este articulo del maestro David Martos en Compartimos en el que aun tenemos ganas de las segundas partes) y me gustaría profundizar un poco sobre este tema.

Muchas vez nos escusamos en que no tenemos tiempo (el proyecto tiene que estar para ayer) en realizar estas pruebas unitarias y por lo tanto decidimos NO hacerlas. Primer error y primera mentira el hacer pruebas unitarias no nos hace perder tiempo sino que nos hace ganar tiempo. Y eso es algo que hasta que realmente no te pones ha implementarlas no sabes realmente lo que ganas.

Por qué comento esto? Primero si no hacemos pruebas unitarias y realizamos el despliegue de nuestro proyecto y tenemos un fallo en la creación de una lista, un tipo de contenido o un campo y cuando lo instalamos en la máquina de producción pues vamos  a ponernos a buscar por donde esta fallando nuestra aplicación. La respuesta es que el tiempo este que tardamos en encontrar lo que esta fallando y su causa, es más que lo que nos hubiéramos costado implementar y realizar las pruebas unitarias. Además del considerable retraso en la puesta en marcha de este proyecto, con lo que si estas delante del cliente pues es una perdida de imagen considerable.

Ahora bien no solo por tiempo y por buena imagen ante el cliente es una razón por la que realizar pruebas unitarias. Uno de los motivos es que el realizar estas pruebas te advierten de posibles problemas/puntos críticos de tu aplicación. Si en una prueba unitaria le cuesta un tiempo considerable de ejecución esto nos indica que hay algo más,  es decir que hemos programado algo mal y que conviene revisarlo. Otro punto muy importante es que te obliga a programar de una forma más modulada con lo cual haces que tu aplicación sea más mantenible. Otra gran mejora de las pruebas unitarias es cuantas veces hemos pensado en si cambio esto no pasa nada no afecta a ninguna parte del proyecto y zas realiza la modificación y se monta una hecatombe. Si tienes tus pruebas unitarias las lanzas y antes de realizar cualquier modificación dices STOP vamos a ver que hay en esta parte que ha fallado y no te tiras a la piscina. Los riesgos para las profesiones de alto riesgos a mi personalmente me gusta tener un flotador para no ahogarme y no meterme en un jardin innecesario.

Dicho todo esto ahora vamos a ponernos manos a la obra, tanto en Visual Studio 2010 como 2012 tenemos un proyecto para realizar las pruebas unitarias. Estas pruebas estarán una serie de métodos en los que nos indicara si esta prueba se ha realizado con exito o no y el tiempo que le ha costado ejecutarse. En que consisten estas pruebas pues dependiendo de lo que estemos realizando. Vamos a empezar por la primera piedra de todo proyecto y esta no es otra que la Arquitectura de la Información,es decir. en el esqueleto que va a tener nuestro proyecto. Que contiene este esqueleto pues listas, páginas, Tipos de contenido, etc… Pues naturalmente el primer paso que tenemos que realizar es comprobar que nuestra característica en la que creamos todo este contenido este en el sitio que estamos implementando.

En primer lugar abrimos nuestro Visual Studio y seleccionamos el tipo de Prueba Unitaria

A continuación voy a poner dos tipos de prueba una en la que compruebo que todos los parámetros de iniciación de mi característica están creados y a continuación voy a crearme otra prueba en la que me indica si tengo una lista en mi sitio, si esta lista no esta creada mi prueba fallará.

Para que la prueba unitaria funcione tenemos que seleccionar el tipo de arquitectura de 64 bits porque sino no funcionaria las llamadas que realizamos a SharePoint (uno de los motivos por los que mucha gente indica que no se pueden hacer pruebas unitarias en SharePoint)

Una vez creada la prueba unitaria voy a ejectuar y voy a ver el resultado de la misma.

Una vez ejecutada las pruebas Visual Studio nos proporciona unas estadísticas muy valiosas y útiles en las que indican el % de cobertura de código que tiene nuestro proyecto. En futuros post abordaré mas este tema pero  un 100% de cobertura del código no indica que tu proyecto no tenga ningún fallo pero ayuda mucho a minimizar el número de errores. En las pruebas unitarias y sobre todo en SharePoint no hay que tener el 100% de codigo cubierto por pruebas unitarias, es prácticamente imposible como vamos a realizar la prueba unitaria de un código que lo que realiza es crear una lista o una página dentro de SharePoint? Como siempre que se hacen pruebas unitarias lo que tenemos que realizar es aplicar coherencia y sentido común a las pruebas que realicemos, pero es recomendable que nuestras aplicaciones tengan por lo menos un 80% de cobertura de código.