Grimpi IT Blog

mayo 28, 2011

VAN de Pex, Moles & Code Contracts

Filed under: .NET, Pex, Test Driven Development — grimpi @ 4:26 pm

Hoy a las 18 GMT, voy a presentar en ALT.NET Hispano una VAN de Unit Testing con Pex, Moles y Code Contracts.

Para acceder, pueden hacerlo por live meeting mediante alguno de los siguientes enlaces:

http://snipr.com/virtualaltnet

https://www323.livemeeting.com/cc/usergroups/join?id=van&role=attend

Para el que nunca escuchó hablar de estas tecnologías, esta es la web oficial de Pex.

Desde este link se pueden bajar el PPT de la Presentación que voy a hacer.

Anuncios

marzo 1, 2011

Filosofía del Software: De Karl Popper a TDD y Selenium

Filed under: Arquitectura, Test Driven Development, Testing — grimpi @ 8:59 pm

Karl Popper junto con Kuhn, fueron probablemente los dos epistemólogos mas importantes del siglo pasado. El aporte más significativo que le debemos a Popper, es el falsacionismo como método de constrastación de una teoría científica.
Que dice el falsacionismo? Básicamente que no es posible probar la verdad de una teoría, pero si podemos refutarla. Entonces, un enunciado científico estaría vigente siempre y cuando, no haya podido ser refutado. Por ejemplo, si mi enunciado dice “No existe vida extraterrestre”, no existe forma de comprobar si este enunciado es verdadero, pero lo aceptamos mientras no se descubra vida exterior. Pero si se descubriera, entonces estaríamos en condiciones de decir la teoría que afirmaba que no existía vida extraterrestre era falsa.
Popper insistía mucho que las teorías científicas debían intentar ser falseadas lo máximo posible. Una buena teoría, es aquella que pudo superar exitosamente muchos intentos de falsearla.
Bien, y que tiene que ver esto con el software?

Todo. El software es excelente ejemplo de la corriente falsacionista popperiana. Jamás podremos decir que un software no tiene bugs. Pero no porque somos humanos y cometemos errores y la perfección es algo divino. No podemos decir que nuestro software no tiene bugs porque no hay forma de demostrarlo afirmativamente. Sin embargo, si podemos llegar a falsear esta afirmación si encontramos errores en el software que diseñamos.
Al igual que lo que afirmaba Popper, un buen software es aquel que ha pasado exitosamente muchos intentos por refutarlo (en nuestro caso, por hacerlo fallar).
El problema que testear un software, es una tarea compleja que debe ser llevada por distintas personas. Como ser un buen popperiano mientras testeamos?

  • Uso intensivo de pruebas unitarias: No importa si usamos TDD, BDD, TAD. No importa si usamos mocking o no. No importa si usamos xUnit, VSUnit, NUnit o no. Lo mas importante de todo, es que nuestro código tenga la mayor cantidad posible de pruebas unitarias (o de integración) posibles. Y esto no significa hacer un método de prueba por método de clase, sino tal vez, hacer varias pruebas unitarias por un solo método, si este es bastante complejo.
    Si nuestra clase esta expuesta para otros desarrollos, hay que probar también que pasa cuando se le ingresan valores no esperados (parámetros nulos, valores aleatorios totalmente fuera del rango esperado, etc.).
    Muchos programadores se sienten demasiado seguros cuando tienen muchos test unitarios en “green flag”. Sin embargo, este tipo de metodología lo que mejor garantiza es que una modificación de código no produzca que otro pedazo de código deje de funcionar. Pero no es suficiente.
    Las pruebas unitarias pueden no enfocarse solamente en probar el código base (sea C#, Java, Ruby o lo que fuese), sino también se podría hacer con Javascript y objetos de una base de datos.
  • Hacer stress testing: Muchas aplicaciones son desarrolladas en entornos incorrectos con un volumen de datos muy bajo en relación con el entorno que va a existir en producción. Esto es un gravísimo error. Porque después se sube la aplicación a producción, pensando que tiene una performance aceptable y nos encontramos al poco tiempo, con que las consultas a la base no estaban optimizadas, no hay estrategia de cacheo de datos, hay métodos que hacen uso intensivo del procesador que están mal programados y nos encontramos en producción con un montón de problemas de performance que no tuvimos en cuenta por desarrollar en un entorno muy distinto al real.
    Esto suele suceder por varias razones. En primer lugar, cuando desarrollamos una aplicación de cero, no tenemos un conjunto de datos reales de producción, entonces nuestras tablas están semivacías con los datos mínimos para poder desarrollarla. Todo funciona rapidísimo, nuestros reportes vuelan. Ahora cuando la tabla pasa de tener 20 registros a 5 millones en producción, recibimos un llamado diciendo “Houston, tenemos un problema…”
    Si no tenemos datos reales para desarrollar, debemos simularlos. Esto se puede hacer manualmente o con muchas herramientas que existen en el mercado. Visual Studio 2008/2010 tiene esa posibilidad. También Red Gate tiene un producto que se llama SQL Data Generator muy bueno.
    Es lo que se llama un test de carga de datos (Load testing).
    Otra situación que nos presente inconveniente es la concurrencia. Y esto es algo mucho más difícil de simular en desarrollo. Tener una base de datos grande es fácil. Ahora como hacemos para tener 10.000 usuarios concurrentes para desarrollo? Imposible. La mejor manera de hacer esto entonces es usar herramientas de stress testing que simulen un cuadro así. En Java existe una excelente herramienta llamada JMeter. Visual Studio ofrece una herramienta parecida (Web Application Stress). Existe este excelente portal con un compilado de distintas aplicaciones open source y gratuitas de testeo muy recomendable.
    Es lo que se llama un stress testing de concurrencia (Stress testing).
  • Test de funcionalidad: Bueno, este es el punto fuerte de QA. En una organización grande no puede faltar. Se debe verificar que el sistema haga lo que esta contemplado que haga. Se debe tener un buen documento de casos de usos y que resultados se esperan. En una empresa donde el testeo es mas “casero”, una de los principios básicos es que el que desarrollo la aplicación, no debe testearla.
    Una muy buena herramienta para automatizar test funcionales de aplicaciones web es Selenium.
  • Test de UI: Esta relacionado con el test de funcionalidad, pero se dedica a buscar errores en la UI (que son mucho mas difíciles de ser detectados en una prueba unitaria). Las validaciones son correctas? Que pasa si se deja campos en blanco o se ingresan valores extremos? Se pide confirmación cuando se van a realizar una operación de borrado o critica del negocio? Como funciona en distintas configuraciones regionales y en distintas resoluciones de pantalla? Como se muestran los errores de aplicación? Como funciona en los distintos navegadores? Que pasa si deshabilito la ejecución de javascript?
    También se deben probar elementos relacionados con la seguridad. Que pasa si modifico manualmente los valores de un querystring? Esta cubierta contra ataques de SQL Injection y XSS Injection? Que pasa si una aplicación externa intenta inyectar peticiones GET y POST a nuestra aplicación?
    WaitR y WaitN (lamentablemente discontinuado) son muy buenas herramientas para automatizar este tipo de test. También podemos usar Selenium.

Links Interesantes:
Performance Testing Guidance for Web Applications
Open Source Testing

diciembre 17, 2010

Como hacer unit testing contra la base de datos?

Filed under: .NET, Arquitectura, Mocks, Test Driven Development — grimpi @ 6:30 pm

Hoy en día el desarrollo de software, no se concibe si unit testing. Hasta el famoso “Hola Mundo” debe tener su respectiva clase de testing…
Uno de los principales problemas que surge a la hora de crear los test unitarios, es como probar contra la base de datos.
Donde está el problema? Supongamos que hacemos un test unitario “Login” que valide el usuario con una password incorrecta ingresada a propósito para ver falla el login. Y supongamos que en la lógica de negocio, al tercer intento fallido de login se bloquee el usuario.
Que va a pasar si tenemos otro test unitario, que intenta probar el login exitoso si ya testeamos tres veces el test unitario anterior? Va a fallar, porque en la base de datos, el usuario quedo marcado como bloqueado.

Para ser más claro, si nuestros test unitarios “ensucian” la base de datos, existe una gran posibilidad de que fallen y no por culpa de que están mal escritos o hay un bug en el código, sino porque los datos no son los que esperamos que fuesemos.

Para solucionar este problema, existen diversas técnicas:

  • Resetear los datos de la base de datos antes de cada tests.
  • Hacer que el test corra dentro de una transacción distribuida y luego hacer un rollback de la transacción.
  • Resetear solo los datos usados por el test, después de que este haya corrido.
  • Usar mecanismo de versionado de datos incorporados en las nuevas versiones de SQL Server o Oracle (flashback tables).
  • Separar el test unitario de la base de datos (mocks).

Obviamente cada una de estas técnicas, tienen sus respectivas ventajas y desventajas. Vamos a empezar de la simple, a la más compleja.

Resetear los datos de la base de datos antes de cada tests.
Esta es la primera opción que viene a la mente. La principal ventaja es su facilidad de implementación.
Una opción practica para hacer esto es tener un backup de la base de datos “limpio” y restorearlo cada vez que se ejecuta un unit testing.
Otra opción es tener un set de datos especifico necesario para el testeo y cargarlo manualmente. Luego del testo, estos datos son reseteados. Existen frameworks como NDbUnit (hhttp://code.google.com/p/ndbunit/) o TDUnit (http://tdunit.codeplex.com/) que nos facilitan enormemente esta tarea. Básicamente funcionan configurando un xml de datos y llamando a una instrucción de carga de datos en cada test unitario.

Ejemplo de código con NDBUnit:

public void Test()
{
string connectionString = “server=localhost;user=dbuser;password=dbpassword;initial catalog=MyDatabase;” ;
NDbUnit.Core.INDbUnitTest mySqlDatabase = new
NDbUnit.Core.SqlClient.SqlDbUnitTest(connectionString);

mySqlDatabase.ReadXmlSchema(@”..\..\MyDataset.xsd”);
mySqlDatabase.ReadXml(@”..\..\MyTestdata.xml”);
}

La principal desventaja de este sistema es obvia. Performance. Limpiar y cargar los datos por cada test unitario, puede ser algo extremadamente costoso en cuanto a tiempos.

Hacer que el test corra dentro de una transacción y luego hacer un rollback de la transacción

Este mecanismo es tentadoramente simple, sin embargo, pocas personas lo deben usar.
Cada test que se corre, está dentro de una transacción distribuida (COM+) que al finalizar, hacemos un rollback. De esta manera extremadamente simple, mantenemos el estado de los datos de la base de datos en cada test.
El problema de este enfoque, es que las transacciones distribuidas son las lentas que las locales. Por otro lado, en determinados entornos, hacer que las transacciones distribuidas funciones, requieren de cierta configuración de Windows.
Existe una extensión para NUnit llamada XtUnit, que entre otras cosas, permite ponerle el atributo [Rollback] al método de testing y automáticamente este unit testing va a correr dentro de una transacción distribuida sin necesidad de que tengamos que escribir código adicional.

Ejemplo de Test con XtUnit:

[Test,DataRollBack]

public void Insert()

{

CustomerService custom = new
CustomerService();

custom.add(“Esteban”,29,21452367);

}

Ejemplo de test sin NUnit solo:

[Test]
public void Insert()
{
using (TransactionScope scope = new TransactionScope())
{
CustomerService custom = new
CustomerService();

custom.add(“Esteban”,29,21452367);
scope.rollback();
}
}

Resetear solo los datos usados por el test, después de que este haya corrido

Este enfoque evita tener que resetear toda la base de datos antes de que el test sea ejecutado. En cambio, se carga una serie de comandos típicamente de insert/delete antes y después de cada test. Las buenas noticias es que de esta manera el menor el trabajo adicional que se ejecuta y por lo tanto, mejora significativamente la performance.
El problema de esta técnica, es que uno debe conocer con antelación que datos va a necesitar el test y si nos olvidamos de insertar un dato necesario, puede que falle el test unitario no por un bug o error de diseño, sino por un simple olvido a la hora de insertar un registro en una tabla antes de que sea ejecutado el test.

Usar mecanismo de versionado de datos incorporados en las nuevas versiones de SQL Server o Oracle

Este es un enfoque bastante interesante y que nos ahorra escribir código. Las últimas versiones de las bases de datos modernas, incorporan la capacidad de hacer versionado de datos sobre las tablas. Cada vez que se hace un insert/update/delete, el dato anterior es guardado en otra tabla interna del motor con un timestamp, existiendo la posibilidad más adelante de consultar el estado de los datos en un momento determinado y de volver la tabla a ese estado.
En Oracle esta característica se llaman Flashback table y en SQL Server Change Tracking.
La ventaja de esta técnica es que no tengo que escribir manualmente el reseteado de los datos ni tengo que lidiar con transacciones distribuidas. Sin embargo, las desventajas son múltiples. En primer lugar, esta técnica solo funciona con las versiones más modernas de las bases de datos Oracle, SQL Server y Postgres. Por ejemplo, no sería posible hacerlo con SQL Server 2005. MySQL en ninguna versión tiene esta característica. Por otra parte, habilitar esta opción en la base de datos tiene un altísimo impacto en performance y en tamaño en disco. Por último, para habilitar esta opción, hay que hacerlo desde el motor de la base de datos.
Para pesar de todas estas desventajas, creo que es una técnica útil en determinados casos puntuales. Especialmente en situaciones donde no tenemos tiempo o no podemos escribir código.

Separar el test unitario de la base de datos (mocking)

Aquí presentamos la opción supuestamente “correcta” de la industria actualmente. Evitar a toda costa el test unitario contra la base de datos y reemplazarlo por mocks, que son clases que emulan el comportamiento de una base de datos (o de cualquier otra cosa que queramos, como web services por ejemplo), de tal manera que podemos probar si el método funciona como deseamos sin conectarse con la BD.
Existen varios frameworks de mocking (NMocks, Rhino, Typemock y Moq). En general son bastante parecidos en cuanto a funcionalidades básicas, aunque algunos son un poco más claros que otros. Personalmente me siento más cómodo trabajando con Moq.

Usar mocking como método de testeo unitario en reemplazo de la base de datos tiene varias ventajas. La primera es la velocidad. No es lo mismo ejecutar 300 test unitarios contra la BD que contra clases en memoria.

La segunda ventaja es la inmutabilidad de los datos. Al no correr contra una base de datos, no se modifica realmente ningún dato, lo que permite que se pueda simular siempre el mismo estado. Para esto es necesario que se cargue al objeto mock con el que se prueba, los valores iniciales que se necesitan, para que el test unitario no falle. O sea, el uso de mocking nos evita todos los problemas que vimos en las 4 soluciones del anterior post.

El uso de mocking también agrega mas previsibilidad al test unitario, cuando no tenemos mucho control sobre la fuente contra la que se prueba o esta tiene un comportamiento indeterminado, como por ejemplo, un monitor de red que prueba x tipo de paquetes. Son situaciones muy específicas y puntuales, pero en esos casos el uso de mocking resulta casi indispensable.

Pero este enfoque también tiene sus desventajas. En primer lugar, no es una prueba “real”. Es una simulación. Hay situaciones en las que un test unitario contra un mock puede resultar exitoso, pero en un escenario más real, contra la base de datos, puede que falle. Por ejemplo, en el caso de que un método llame un store procedure y devuelva determinado conjunto de datos. Si el store procedure fue por cuestiones de negocio modificado sin nuestro conocimiento de tal manera, que el resultado de salida cambie, si probamos contra el mock nunca nos vamos a enterar de esta modificación.

También puede darse el caso de que haya cambios en la estructura de una tabla o falten permisos. Todas situaciones que si no tenemos aviso, podrían hacer que el test unitario corra exitosamente cuando no debería.

Otra desventaja de esta técnica, es que no es inerte a como está el código de la aplicación. Para ser más claro, para que una clase de nuestra aplicación, sea “mockeable” debe estar programada para esto.

Debe estar hecha de tal manera, que uno pueda inyectar instancias distintas. Uno puede decir y de manera bastante correcta, que es una buena práctica que las clases permitan inyección de código. Puede ser, pero también es discutible. Depende de las características de la aplicación.

Pero el caso es que uno no puede mockear una clase si no pensó antes en que iba a usar esta técnica de test unitario. Claro que si uno trabaja con TDD no tenga este tipo de problemas, pero no todo el mundo trabaja así y ni tiene porque hacerlo.

Otra desventaja es que uno tiene que decirle a la clase mock, que valores espera. Las expectations. Ejemplo:


Lo que resulta un poco engorroso a veces si la función es compleja.

Como verán, soy bastante crítico de este tipo de soluciones. Mi principal problema es que agregan complejidad al código y más complejidad, es mayor probabilidad de errores. El test unitario tiene que ser lo más simple posible, tener la menor cantidad de errores. Y agregar mocks significa todo lo contrario.

Por supuesto, que se gana en velocidad. El tema es el siguiente: Constantemente estamos corriendo 300 test unitarios? Yo personalmente solo corro los tests unitarios de los métodos y clases que estoy tocando en este momento o calculo que pueden llegarse a verse afectados. En todo caso, al final del día, se corre todos los test para verificar que no se suba nada que rompa el código, pero tiene sentido hacerlo continuamente?

Y si no es así, entonces cuanto es la ganancia de velocidad?

También uno puede plantear soluciones intermedias. Probar las clases repository o DAO o aquellas clases de bajo nivel cuya función es trabajar con la base de datos sin mockeo y las clases de negocio, usando mock. De esta manera, al probar tanto contra la base de datos y contra una clase mock, estoy ganando fiabilidad en el test (al probar los repository directamente contra la BD) y por otro lado, también gano velocidad al evitar testear las clases de negocio contra la BD.

Muchos dicen por otra parte, que no hay que confundir un test de integración con un test unitario. El test de integración se prueba con la base de datos y el test unitario no. Es una práctica habitual escribir estos 2 tipos distintos de test para una misma función. Es una opción bastante prolija, pero el costo es la duplicación de código de testing.

De todas maneras, más allá de los gustos personales de cada uno, esta solución existe y puede ser altamente recomendable en determinadas situaciones puntuales.

Como ya deberíamos saber, cuando uno desarrolla, existen múltiples formas de hacer lo mismo indistintamente en el 80% de los casos. Pero siempre, existe ese 20% restante, donde determinada forma es claramente más conveniente que las otras.

febrero 6, 2009

Introducción a Test Driven Development (TDD)

Filed under: Arquitectura, Patrones, Test Driven Development — Etiquetas: — grimpi @ 10:46 pm

Test Driven Development (TDD) es una metodología de programación que involucra 2 prácticas: Escribir primero las pruebas unitarias, o sea, escribir el test antes de escribir el programa y refactoring.
Yo creo que una de las cosas más difíciles al trabajar de esta manera, es cambiar la mentalidad con la que estamos acostumbrados a desarrollar.
TDD es un proceso interactivo donde se repiten una serie de pasos hasta que se está satisfecho con el código generado. A TDD no le importa demasiado como está estructurado el código ni la arquitectura del software. La manera en que TDD trabaja es mediante requerimientos o casos de usos, que son descompuestos en un conjunto de comportamientos más chicos necesarios para cumplir con el caso de uso dado. Luego por cada comportamiento del sistema, lo primero que se debe hacer es escribir un test unitario para dicha funcionalidad.

Hay muchos conceptos confusos alrededor de esta técnica que me gustaría aclarar:

  • Primero las pruebas unitarias, luego el código de los métodos (Test-First Development). Este concepto es una de las características fundamentales de TDD. Si no respetamos esto, no estamos haciendo TDD (lo que tampoco tiene porque estar mal, pero es necesario hacer la aclaración sobre lo que no es TDD).
  • TDD no es una técnica de testing. TDD apunta a desarrollar software de manera incremental de la forma más simple y robusta posible.
  • Mucha gente tiene cierto rechazo porque piensa que TDD consiste en escribir TODAS las pruebas unitarias antes que el código. Esto es falso y es importante remarcarlo. TDD consiste en hacer un desarrollo cíclico e incremental. Se debe generar inicialmente un conjunto muy limitado de test que corresponden a una clase o caso de uso, para luego ir desarrollando el código. Una vez que toda la funcionalidad correspondiente a las pruebas unitarias fueron desarrolladas, se pasa a otro modulo.
  • A pesar de lo que siempre se dice que en TDD lo primero que hay que hacer es escribir el test unitario antes del código, esto tiene un límite obvio y es que la estructura de la entidad que vamos a probar ya debe estar creada. Por ejemplo, si vamos a desarrollar una clase que administre clientes, conviene primero crear la clase entidad Cliente, con sus respectivas propiedades, luego las pruebas unitarias y por último los métodos de la clase Cliente (que pueden ser insertar, modificar, validar, etc.).

Ciclo del TDD:

1) Escribir un test e intentar compilar, aunque aun no sea posible porque no se desarrollo la funcionalidad correspondiente.

2) Escribir la mínima cantidad de código posible para que la prueba unitaria compile y ejecutarla. Deberá fallar, ya que no tiene la funcionalidad requerida.

3) Escribir el test de tal manera, que al ser ejecutado, este no falle. La idea es que la función escrita no sea lo más elegante y optimo posible, sino que simplemente, permita pasar el test unitario exitosamente.

4) Refactorizar el código de la función, para que sea lo más optimo posible. Es muy posible que existan varias instancias de refactorización del código de la función en distintas etapas del proyecto.

5) Escribir un nuevo test unitario para otra funcionalidad.


Ventajas:

Todo muy lindo lo explicado, pero que ventajas concretas ofrece trabajar con TDD? Porque conviene trabajar con esta metodología?

  • En primer lugar y la ventaja más obvia, es que al tener el test unitario escrito por cada método, podemos detectar regresiones y cambios en una función que rompan otra parte del código.
  • Mayor facilidad para refactorizar y mantener código.
  • Si bien es verdad que TDD significa en un principio escribir más código, la realidad indica que muchas veces ahorra código y tiempo, al disminuir la cantidad de defectos en los métodos.
  • Al desarrollar el método de acceso al método antes que su implementación, ayuda a pensar cómo utilizar el componente y para que debería existir, por lo tanto, nos ayuda al diseño del software.

Recomendaciones:

  • Hacer más de un test unitario por función que contemplen distintas situaciones. Se deben probar la mayor cantidad de casos posibles. Es MUY recomendable hacer un test unitario negativo, o sea, que si no devuelve una excepción o el resultado de llamar al método es distinto de false, es porque hay un error. Por ejemplo, si es una regla de negocio, hacer un test unitario para que contemple la validación exitosa y otro test unitario, que llame al método con parámetros incorrectos para probar que la validación la está haciendo de manera correcta.
  • No meter lógica en los test unitarios. Si queremos probar distintas situaciones, usemos un test unitario por cada prueba.
  • No hacer que un test unitario dependa de otro test. Deben ser lo más independientes posibles uno del otro.

TDD vs TAC:

Uno de los componentes principales de TDD es Test First Development, que como ya dijimos antes, consiste en escribir el test unitario antes que el código. Pero sin embargo, existe otro enfoque más tradicional, que es precisamente el inverso. Escribir el test unitario DESPUES de haber escrito el código y a esto se lo llama Test After Coding (TAC).

Escribir antes el test unitario nos garantiza que todos los métodos y funciones de nuestra aplicación, tengan su respectivo test unitario. En cambio, esto en la práctica, no está garantizado con TAC, ya que siempre se va a estar corriendo con los tiempos.

Por otro lado, TDD nos ayuda a pensar el diseño del software, ya que cuando escribimos el test unitario, debemos pensar en la interfaz del método y como va a interactuar. Si empiezo diseñando la prueba, se hace más claro que tiene que hacer exactamente el método, con lo cual, se podría reducir tiempos y sobre todo, posibilidad de errores.

Otro punto a favor de TDD y muy importante, la primera vez que se ejecuta el test unitario, este debe fallar. Si el test al ser ejecutado, pasa exitosamente, es porque está mal escrito. Sin embargo, si el test fue escrito posteriormente al desarrollo del método, existe la posibilidad de no poder detectar que el test unitario en si mismo este mal escrito, ya que si siempre se ejecuta exitosamente, uno tiende a pensar que el método esta correcto y dificulta la tarea de ver si el test unitario está correcto. Esto es fundamental.

Ejemplo de código:

Pongamos un poco de TDD en acción y veamos un ejemplo simple pero práctico de cómo usar esta metodología de trabajo.

Supongamos que nos piden desarrollar modulo que permita insertar, modificar, listar y eliminar clientes. A su vez también tenemos que programar un método de validación que cumpla con la siguiente regla de negocio del cliente: Debe tener menos de 50 años, el sexo solo puede ser F o M, y el nombre es un campo obligatorio.

Para simplificar, vamos a usar el patrón Active Record (del cual ya habíamos hablado antes), que nos permite en una misma clase poner la lógica de negocio y de acceso a datos.

public class Cliente
{

private string nombre;
private int edad;
private string sexo;

public string Sexo
{

get { return sexo; }
set { sexo = value; }

}

public int Edad
{

get { return edad; }

set { edad = value; }

}

public string Nombre
{

get { return nombre; }
set { nombre = value; }

}

}

Ahora debemos crear la clase ClienteTest y para reducir el ejemplo, vamos a crear solamente 2 pruebas unitarias (Validar e Insertar)

  • 1° Fase

[TestClass()]

public class ClienteTest

{

[TestMethod()]

public void InsertarTest()

{

Cliente nuevo = new Cliente();

nuevo.Edad = 35;

nuevo.Sexo = “F”;

nuevo.Nombre = “Alejandra”;

bool resultado = Cliente.Insert(nuevo);

Assert.AreEqual(resultado, true);

}

[TestMethod()]

public void ValidarTest()

{

Cliente nuevo = new Cliente();

nuevo.Edad = 50;

nuevo.Sexo = “F”;

nuevo.Nombre = “Alejandra”;

bool resultado = nuevo.Validate();

Assert.AreEqual(resultado, true);

}

}

Obviamente este codigo no va a compilar, ya que los metodos de la clase Cliente todavia no fueron siquiera declarados.

  • 2° Fase

Ahora debemos crear en la Clase Cliente, los 2 metodos que vamos a utilizar, pero con el UNICO objetivo que las pruebas unitarias puedan compilar y fallar al ser ejecutadas.


///
<summary>

/// Valida que el el cliente cumpla con las reglas de negocio.

///</summary>

public bool Validate()

{

return false;

}

///<summary>

/// Inserta un nuevo Cliente en la base de datos.

///</summary>

public static bool Insert(Cliente nuevo)

{

return false;

}

  • 3° Fase

Corremos todos los test unitarios desarrollados y estos deben fallar (Red Status)


  • 4° Fase

Desarrollamos los 2 métodos correspondientes a los test unitarios (para el segundo método, no lo desarrolle completo para no hacer largo el código y clarificar lo que se quiere hacer).


public bool Validate()

{

if (edad < 50) return false;

if (String.IsNullOrEmpty(sexo)) return false;

if (!sexo.Equals(“F”) && !sexo.Equals(“M”)) return false;

if (String.IsNullOrEmpty(nombre)) return false;

return true;

}

public static bool Insert(Cliente nuevo)

{

try

{

using (SqlConnection conn = new SqlConnection(“CONNECTION_STRING”))

{

using (SqlCommand command = new SqlCommand(“INSERT INTO CLIENTES …”))

{

command.ExecuteNonQuery();

}

}

return true;

}

catch

{

return false;

}

}

  • 5° Fase

Corremos todos los test unitarios desarrollados y ahora estos deben pasar exitosamente (Green Status)


Links:

Blog de WordPress.com.