Grimpi IT Blog

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

Dejar un comentario »

Aún no hay comentarios.

RSS feed for comments on this post. TrackBack URI

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Blog de WordPress.com.

A %d blogueros les gusta esto: