Archivo de la etiqueta: testing

Las 5 maneras en las que hago pruebas con ASP.NET

Al desarrollar aplicaciones en ASP.NET, tener un buen conjunto de pruebas es la diferencia entre encontrarte un fallo en desarrollo o en producción, así de sencillo. Las pruebas no evitan todos los errores, pero al menos nos permite que los caminos críticos se mantengan estables. Veamos de qué manera podemos probar nuestras aplicaciones ASP.net

1. Pruebas Unitarias

En una prueba unitaria probamos habitualmente los métodos y el comportamiento de una clase, aunque, por supuesto, no es necesario probar TODOS los métodos (getters y setters, por ejemplo, a menos que tengamos algun tipo de lógica de validación dentro de los mismos).

En una prueba unitaria, además, es importante que mantengamos aislada la clase a probar, de tal manera que todos los servicios o clases externas puedan ser simulados mediante mocks o clases de test específicas. Para estos mocks podemos recurrir a librerías como Moq.

Backend

Personalmente he utilizado tanto MSTest, NUnit como XUnit, estando más familiarizado con el primero ya que lo uso a diario. En general cada framework tiene sus características que lo hacen más interesante, aunque todo se reduce a encontar aquel con el que más cómodos nos sintamos.

Frontend

Si nuestra página contiene lógica de lado de cliente (por ejemplo, si estamos diseñando una SPA con Angular, Knockout o React) se hace prácticamente imprescindible el uso de tests. Para ello podemos recurrir a frameworks como QUnit, Jasmine o Mocha, herramientas que nos permiten establecer unas condiciones para crear tests, así como proporcionarnos un entorno de ejecución para ejecutar las mismas.

Estas herramientas, además, se pueden integrar con Visual Studio y también con Team Foundation Server/Visual Studio Online mediante la extensión Chutzpah que podemos agregar a nuestra solución.

2. Pruebas de integración

En una prueba de integración probamos la interacción entre diferentes módulos de nuestra aplicación, y en este caso el objetivo es asegurarnos que ciertos caminos funcionan correctamente entre las diferentes capas de la misma. Una prueba de aceptación no tiene por qué cubrir todo el sistema, sino que puede cubrir tan solo una parte del mismo.

Un ejemplo podría ser comprobar que el valor que llega a un controlador, pasa por la capa que valida la lógica de negocio de ese valor y finalmente devuelve una respuesta correcta, simulando la inserción en la base de datos.

Mientras más fuertes sean nuestras pruebas de integración entre componentes del sistema, más facilidad tendremos para encontrar y corregir posibles errores de regresión que no hayamos encontrado en pruebas unitarias, ya que, habitualmente, es en la interacción en donde pueden surgir más problemas inesperados.

3. Pruebas de UI

Una de las cosas que más problemas nos puede dar es no saber si los caminos críticos de nuestra web están funcionando correctamente, y para ello, la única manera de poder asegurarnos al 100% es mediante una prueba que simule un usuario navegando por la página. Para este cometido podemos utilizar Selenium, que nos permite grabar el comportamiento de un usuario en nuestra página y posteriormente reproducirlo, así como escribir este comportamiento en C# y ejecutarlo como si de un test de integración se tratara.

4. Pruebas de carga

¿Qué pasa cuando la aplicación recibe 1000 usuarios de golpe? ¿Soportará un “efecto menéame?. Benditos problemas, pero problemas al fin y al cabo. Si estamos trabajando en una solución que tenga que soportar cierta carga (prensa, bancos, redes sociales…) las pruebas de carga deben formar parte de nuestro plan de pruebas, ya que nos permitirán estresar el sistema y poder descubrir otro tipo de errores. Una de las herramientas para realizar estas pruebas de carga es JMeter del proyecto Apache, que nos permite además personalizar la salida de estas pruebas y poder ver los resultados como listas o como gráficas.

5. Tests exploratorios

Este tipo de pruebas resulta bastante interesante y ya hemos hablado de ellas en alguna ocasión ya que mezclan intuición y experiencia adquirida, para intentar encontrar nuevos fallos, errores o escenarios que se escapen del uso habitual del sistema (los denominados también “Corner cases”).

La ventaja de estos tests es que nos aportan un mayor conocimiento sobre el sistema, aunque pueden resultar difíciles de realizar o incluso tediosos, aunque hemos de pensar que no estamos haciendo el trabajo de la máquina, sino intentando ir un poco más allá.

Conclusiones

Aunque los test exploratorios pueden caer fuera del ciclo habitual de test de una tarea, no es conveniente dejarlos fuera, ya que nos pueden aportar mucho conocimiento sobre una herramienta, sobre todo si tenemos que trabajar con código heredado.

Estas son solo cinco opciones que personalmente uso o he usado en mi día a día, existen más sabores y tipos de tests, aunque el objetivo de todos es el mismo, asegurar la fiabilidad del código que estamos poniendo en producción.

¿Y tú, qué pruebas haces? Déjame un comentario o hablemos en @rlbisbe

Anuncios

8 cosas aprendidas de Android en el Codemotion 2014

En el pasado Codemotion 2014 pude asistir a varias charlas relacionadas con el desarrollo de aplicaciones para Android, en las que pude aprender y recordar algunos conceptos y herramientas que resumo en este pequeño artículo:

1. Model-View-Presenter

Fuente: Wikipedia DE

Fuente: Wikipedia DE

El patrón Model View Presenter es muy similar a Model View ViewModel en la base, ya que tanto el ViewModel como el Presenter notifican a la vista de los cambios, y reciben los comandos de la misma.

En el caso de Android, se propone el uso de Interfaces entre Presenter y la Vista, de manera que trabajamos, con clases abstractas, consiguiendo cierta independencia con las implementaciones.

2. Arquitecturas hexagonales

El uso de las clases abstractas con los MVP es lo que deriva en una arquitectura hexagonal, en la que mediante puertos (que es como se denominan estas interfaces) nuestra lógica de negocio se comunica con las diferentes abstracciones de la vista y diferentes servicios como comunicaciones o almacenamiento.

Fuente: VICTOR SAVKIN

Fuente: VICTOR SAVKIN

En el caso concreto de Android, la lógica de negocio puede estar completamente aislada en un módulo Java puro, lo que da una mayor independencia de la plataforma.

3. Documentación de calidad mantenida por la comunidad

android-guides

Los manuales de android guides, creados por los chicos de codepath, contienen (a fecha de hoy) más de 100 artículos con guías prácticas de desarrollo, cubriendo temas como fragments, persistencia, o guías completas como cómo empezar con gradle. Resultan verdaderamente interesantes y desde luego es un lugar a añadir a mi lista de favoritos.

4. Motores de Inyección de dependencias

De la misma manera que tenemos ninject en .NET o bien podemos crear nuestro propio motor, para Android tenemos Dagger (para inyección de dependencias en general) y Butterknife (para inyectar vistas), que nos permiten gestionar las dependencias de nuestros objetos (para implementar una arquitectura hexagonal como la que hemos definido anteriormente, por ejemplo).

5. Bases de datos y almacenamiento

url

En función de las necesidades que tengamos, hay dos proyectos que deberíamos tener en cuenta:

  • SugarORM, permite tener una base de datos local de manera extremadamente simple y manejable.
  • ORMLite compatible con cualquier proyecto de Java y permite una mayor personalización y estructuras un poco más complejas, además de estar más extendido en la comunidad.

Además, podemos o bien utilizar la clase ContentProvider para almacenar datos, o bien usar los adaptadores propios del sistema operativo, aunque se recomiendan las dos opciones anteriores.

Web: SugarORM (no confundir con SugarCRM): http://satyan.github.io/sugar/
Web: ORMLite: http://ormlite.com/

6. Testing

Para desarrollo Android tenemos muchas herramientas para hacer testing, desde JUnit que nos permite además de código Java estándar probar código específico para la plataforma, pasando por Mockito para crear artefactos para nuestros tests, y acabando con Espresso, para probar la UI de nuestra aplicación.

7. Programación reactiva

La programación reactiva o Reactive Programming es un paradigma que se basa en el flujo de datos, actualizando la visualización de los mismos a través del envío y recepción de mensajes. Es un tema verdaderamente interesante, ya que mezcla conceptos de programación funcional con patrones de lenguajes orientados a objetos como observer.

8. Otros lenguajes

Uno de los puntos fuertes de la JVM es la capacidad para ejecutar otros lenguajes más allá de Java, de esta manera podemos usar lenguajes como Kotlin (creado por Jetbrains), Groovy o incluso Clojure para hacer aplicaciones Android. El soporte para otros lenguajes es algo que está en proceso, pero que podemos tener en cuenta (Android Studio se lleva bastante bien con Kotlin, por ejemplo). Si nos vamos fuera de la JVM tenemos opciones como Xamarin que nos permite desarrollar apps para Android usando C#.

Conclusiones

Esta lista es solamente un resumen de varias charlas y conversaciones tenidas durante el evento. El ecosistema Android es muy interesante, no solo por todas las herramientas y técnicas disponibles, que una vez aplicadas se pueden llevar a otras plataformas, sino además por la comunidad que tiene, no solamente Android sino el lenguaje Java y los lenguajes basados en la JVM.

Nos vemos en la siguiente, aquí te dejo un recopilación de todas las charlas del Codemotion: https://docs.google.com/spreadsheets/d/14ZjJQ_VeT8mKmO8MANA1Os5zwRA3Pu_rpFdfyFtBZ4A/edit#gid=0