Pruebas

Hoy he probado a probar. He instalado la última versión de NUnit (la 2.2.7) y he decidido probar con uno de nuestros proyectos. La experiencia ha sido intensa para ser la primera vez que intentaba probar un sistema real ya construido (algunos me dirán, con razón, que eso debería haberlo pensado antes, pero equivocarse es una buena manera de aprender).

Bueno, pues sólo por haberlo intentado, ya me he encontrado con ciertas dificultades, que me han servido para reflexionar un poco y llegar a algunas conclusiones.

Diseña para probar
La primera es que el sistema tiene que estar diseñado para ser probado. Es muy difícil probar un sistema que no está pensando con el proceso de pruebas en mente. Los criterios de acoplamiento y cohesión son en mi opinión de especial importancia, y tener este proceso presente favorece su aplicación. En particular, disponer de clases poco acopladas facilita el diseño de los casos de prueba al no ser necesario simular demasiadas de esas clases. Para ilustrar esta reflexión y las siguientes, voy a describir el caso particular que me llevó a ellas.

El sistema es una aplicación web con arquitectura en tres capas (presentación, lógica y datos) con sus funciones habituales. Ciertas operaciones usadas habitualmente por varias clases de la capa de presentación fueron recogidas en varios métodos de clase. Una de estas funciones determina si la IP del navegador pertenece a la red local o no. Su signatura tal y como estaba programada en un principio es la siguiente (Visual Basic.NET):

Public Shared Function EsIPInterna() As Boolean
:

El principal problema era que ¡no recibía ninguna dirección IP! Examinándo el código, comprobe que la dirección IP se obtenía de la cabecera HTTP enviada por el navegador:

:
Dim direccionIp As String = Request.ServerVariables("HOST_ADDRESS") 'O algo así
:

La función dependía internamente de un objeto disponible en el contexto del Internet Information Server de Microsoft. Las pruebas deben ejecutarse en un entorno que desde luego no es el IIS y en el que por tanto no tenemos acceso al objeto Request. Para salvar este primer inconveniente, modifiqué la signatura de la función de esta forma:

Public Shared Function EsIPInterna(ByVal ip As String) As Boolean
:

Y a continuación, cree una nueva función que permitiría no modificar el resto del código:

Public Shared Function EsIPInterna() As Boolean
   Return EsIPInterna(Request.ServerVariables("..."))
End Function

La primera función me permitiría pasar varios argumentos a la función y poder probarla. Lo dicho, las pruebas tienen que estar siempre presentes en el proceso de diseño y construcción.

Prueba la reusabilidad
Como segunda reflexión, he percibido que el proceso de pruebas puede favorecer la reusabilidad. En efecto, el obligar a probar una u otra función con un juego de datos que cubra por ejemplo el criterio de pruebas de caja negra obliga a exponer aquellos parámetros que sean necesarios para ejercitar el código. Esta exposición En otro caso, el sistema debe cambiar para adecuar las pruebas. Mejor hacerlo entonces desde el principio. Lo hemos visto en el caso anterior. La función EsIPInterna que recibe el parámetro podría ser reusada en otros proyectos.

Prueba a desacoplar
Probar un sistema casi obliga a disminuir todo lo posible el acoplamiento. La necesidad de probar las clases por separado fuerza en cierta forma a diseñarlas de manera que dependan lo menos posible unas de otras. Para que el proceso de pruebas sea efectivo, es necesario en todo caso que dicha dependencia sea explícita (por ejemplo, en la forma de parámetros en la construcción). Además, se refuerza la esencia colaborativa del diseño orientado a objetos.

Castillos en el aire
Las pruebas son especialmente difíciles de diseñar en aquellos casos en los que el código depende de alguna plataforma tecnológica, precisamente porque es difícil simular dicha plataforma (salvo que, una vez más, el sistema esté diseñado de forma que lo permita). Ejemplos de dichas plataformas son el servidor web (un IIS en mi caso), o un middleware o monitor transaccional (COM+ en mi caso). En el ejemplo esta reflexión se hace evidente.

Conclusiones
Como resumen, probar te permite orientar tu diseño para permitirte precísamente poder probarlo, aumentar su reusabilidad, disminuir su acoplamiento y abstraer lo más posible tu código de la plataforma tecnológica que estés usando en cada momento. No se le puede pedir más a una función... Veremos a ver qué aprendo de las próximas cientos de miles...

Un momento de furia

Me voy a permitir un momento de queja.

Empezaré describiendo ciertas situaciones que me han sucedido varias veces, y luego terminaré con una conclusión y quizá una petición, un ruego.

Una vez dentro de la estación de metro, te dispones a coger la escalera mecánica para bajar, o para subir. Cuando llegas al otro lado de la escalera, la persona que está inmediatamente delante tuyo se detiene para decidir, allí, en el rellano de la escalera, si debe moverse a la izquierda o a la derecha, o quizá no sabe donde va... Es posible que le haya pasado algo, un mareo o un vaído, o que haya sufrido una hipoglucemia o un breve malestar, pero te aseguro que nunca me ha ocurrido que a la persona de delante haya necesitado a una enfermera o a un sámur.

Ya estás para salir. Subes la escalera, y el fumador que te abandera decide que ya es momento de encender un cigarro. Ha aguantado cerca de media hora sin fumar, y ahora siente que por fin puede dar via libre a su deseo contenido y casi inconscientemente saca el cigarrillo del paquete, lo toma entre los labios, chisca el mechero y lo acerca a la boca. Da la primera calada y expulsa satisfecho la primera bocanada de humo. Esa primera bocanada que, por efecto de la diferencia de temperatura entre el exterior y el interior del metro, va hacia atrás y en particular a tus pulmones, sin pagar peaje.

Tras varios intentos infructuosos (ninguno de ellos violentos hasta ahora), he conseguido sentarme. En el peor de los casos, el individuo a tu derecha se ha sentado de forma que extiende sus piernas hacia los lados, no se ha quitado el plumas a pesar del calor que hace en el vagón, y se dispone a leer un libro o peor, el periódico, acercándolo lo más posible hacia si, lo que provoca que también los codos sigan el mismo camino que sus codos. Sus rodillas pegadas a las tuyas y los codos clavados en tus costillas hacen que el lado derecho de tu cuerpo no se encuentre, digamos, cómodo. Por su parte, la joven a tu izquierda ha decidido que, puesto que no ha encontrado un sitio normal, el reposabrazos en ese mismo lado puede hacer las veces de asentáculo. El bolso colgado de su brazo derecho ha decidido también imitar al codo de la persona a tu izquierda. Por desgracia, la joven tampoco se ha quitado el plumas.

Las puertas de la salida (o de la entrada, depende del sentido que lleves) son conocidas entre los usuarios del metro porque son especialmente costosas de abrir. Así que, como dictan las normas de educación, una vez que has abierto las puertas, la sostienes y esperas a que la persona detrás de ti alargue el brazo y la sujete por ti mientras ella pasa. Si no fuera así, si hubieras soltado la puerta, podrías haber provocado que ésta se fuera hacia la cara del que te sigue, provocando algún daño o lesión. Pero la otra persona, lejos de sujetar la puerta, te ha visto quizá con cara de conserje y aprovechando tu maniobra, hace las necesarias para pasar por el dintel mientras tú, con cara de ingenuo, empiezas a dudar de cuándo deberías soltarla.

Por favor, somos más de cuatro millones de personas aquí en Madrid. Necesitamos colaborar unos con otros. A ¿todos? nos gustaría hacer lo que nos dé la gana, tener todo tipo de asistentes-esclavos para no tener que esforzarnos, estar cómodos en nuestro entorno. Pero si quieremos vivir medianamente bien (lo que significa vivir medianamente como humanos), debemos considerar a los demás, respetarlos. Es BÁSICO. Es quizá uno de los valores que vamos perdiendo cada vez más. El respeto es tener en consideración a los demás, primero por compartir la misma naturaleza, luego por la posesión de ciertos valores que igualmente respetamos, por ejemplo, la edad o la situación personal, o por qué no decirlo, por su cargo, por su autoridad... La cortesía es la expresión de ese respeto que tenemos por los demás, y en última instancia a nosotros mismos (el respeto por los demás empieza en el respeto por uno mismo).

¡Buff! Bueno, pues ya.

Vida y muerte

El trágicamente doloroso sentir que las cosas que ves, la gente que conoces, tu familia, tus amigos, tu mujer o tu novia; aquello por lo que has luchado, lo que has ganado, lo que has creado, lo que has hecho; todo lo que has sentido, todos tus recuerdos, tus emociones, lo que has visto; todo tu dinero... Todo. Absolutamente todo, desaparecerá algún día. Algún día, porque tú mismo desaparecerás.

Y todavía el día que desaparezcas, bueno, tampoco será tan trágico. Al fin y al cabo como decía aquel

No debes preocuparte por tu muerte, porque cuando tú estás, ella no, y cuando ella está tú no.

Pero ¿y todo aquello que desaparecerá cuando tú estés? Piénsalo.

Sin embargo, hay un efecto curioso. Cuanto más piensas en esas cosas, cuanto más piensa en tu muerte y en la de todas las demás cosas y personas, más te alegras de estar vivo e igualmente de que estén vivas todas las cosas y personas que te rodean. Y que no van a estar ahí para siempre.

Ahora no me extraña que el Bushido Shoshinshu empezará directa y claramente:

No dejes de pensar en la muerte. En cada momento.

Vive tu vida, pensando en tu muerte.

Einstein

Ayer estuve en una charla de la Cátedra de Ciencia, Tecnología y Religión, organizada por la Universidad Pontificia Comillas.

Me considero una persona de cerebro inquieto, y me gustan mucho áreas de conocimiento como informática, astronomía, matemáticas, psicología... O sea, soy más bien del lado de las ciencias, sean biológicas, físicas, humanas o del conocimiento, y en particular, me gusta la relación que tienen esas áreas con otras que domino menos, pero que también me provocan cierta curiosidad, como la teología, la filosofía o la religión. Soy un firme defensor del efecto Medici (como siempre, Google encontrará por ti mucha información en inglés o en español).

Asi que era normal que me interesara el tema de la Cátedra, que esta vez relacionaba la figura científica de Einstein con su pensamiento. Aunque no era lo que se entiende por una persona religiosa, si es cierto que tenía una concepción de Dios muy profunda y muy newtoniana, es decir, la de un magnífico relojero, no intervencionista en la vida de los seres humanos, a los que dio la primera cuerda y que poco después permanecía absorto contemplando la obra y la exacta forma en la que todo funcionaba.

Que duda cabe de que el Einstein científico (hasta 1919, en el que se confirmaron sus teorías gracias a un eclipse de Sol) y el Einstein figura pública (desde ese año, en el que le alcanzó la fama) son los más conocidos, pero sería muy interesante estudiar su aspecto más humano. De especial interés son el divorcio de su primera mujer (precisamente en ese mismo año 1919) o la relación con otros científicos y físicos de su época, sobre todo aquellos relacionados con la mecánica cuántica.

Comentaré en mi diario otros temas relacionados con Einstein según me vayan llegando a mi memoria.

Presentación

Este soy yo.



La única diferencia es que no llevo gafas, no llevo corbata, todavía no he caído en la tentación de llevar un par de bolis en el bolsillo de la camisa, y bueno, el pelo sí se parece un poco. En lo demás, soy idéntico.

Soy ingeniero software. El nombre parece un poco presuntuoso, pero lo más importante sobre él es que todavía no está claro qué significa ser "ingeniero del software". Algunos, los más radicales, nos niegan el título de "ingeniero".

Es verdad que nuestra profesión (¿alguien por ahí piensa que no existe?) está todavía un poco verde. El cuerpo de conocimiento no parece estar muy bien definido, por ejemplo, aunque hay la ACM y la IEEE están metidas en el proyecto swebok (Software Engineering Body of Knowledge).

¡Ay! Me pasa que cuando intento pensar sobre un tema, me da la sensación de que he leído mucho, pero que sé muy poco. Que mucho pasó por mis ojos, pero que poco de ello permaneció en mi memoria, o mejor, en mi entendimiento. Creo que voy a hacer una lista con las cosas que me gustaría saber bien, y ponerme en serio a estudiarlas.