Muy buena discusión.
Aporto algunas ideas, probablemente muy teñidas de subjetividad, pero que tal vez aún así sirvan para algo. Trabajar intensivamente con tests fue uno de los cambios más importantes en mi vida como programador, tal vez tan importante como pasar de Pascal a Smalltalk. Siempre me pregunto porqué suceden este tipo de cosas, tratando de centrarme no tanto en el objeto, es decir, la tecnología, si no en el sujeto, es decir, la mente del programador, o sea, la mia. Hernán dice al pasar que aplicar test es tirarle el trabajo a la computadora para poder pensar más en otras cosas y esto me parece que es un aspecto fundamental. Esto me lleva a una pregunta que se sale totalmente de las cuestiones técnicas, pues al hablar de nuestra cabeza y la forma en que la utilizamos, forzosamente nos salimos de la informática y vamos a un terreno menos explorado, la psicología del programador. ¿Por qué programamos? (O en todo caso, ¿por qué programo?) Una primera respuesta sería: por que nos gusta pensar. Es un pensamiento tendiente más a lo analítico-racional que a lo intuitivo, como el del matemático, pero no tanto, y por eso no somos matemáticos. Acaso nuestros estilos, nuestros gustos como programadores puedan definirse por el grado de combinación entre el pensamiento deductivo y el intuitivo. Pero más allá de esta difícil cuestión, lo que quiero destacar es que ese gusto por pensar tiene que tener ciertas características para que no sea simplemente una patología: es posible pensar mucho y muy analíticamente sin llegar a ninguna parte. Obviamente, nuestro límite más grande es que la programación genera un producto sujeto a una validación inmediata: el programa tiene que funcionar, aquí y ahora. Pero volviendo a lo que es estrictamente la actividad de programar, nuestro aliado más grande es una vieja característica de la naturaleza humana (y de la naturaleza en general, por qué no) que es la economía. Economía en sentido amplio, no economía monetaria: lo que a veces se llama economía de esfuerzo. Lo que nos maravilla de la tan mentada elegancia matemática no es otra cosa que la economía. Cada vez que podemos olvidarnos de que abajo de nuestro Smalltalk hay un sistema operativo, cada vez que delegamos una responsabilidad en otros objetos, cada vez que confiamos en un framework, estamos liberando memoria de nuestras mentes que en lugar de ocuparse de asuntos de otros, se puede ocupar de los propios. Se podría definir la actividad de programar como tratar de resolver cuestiones cada vez más complejas mediante soluciones cada vez más simples. Llevándolo al extremo, cuando la economía ha logrado una simplificación total, no hace falta programar. Es el caso de como laburan muchos programadores actualmente, pegando cosas, configurando, llenando especificaciones, pero sin escribir una línea de código, o muy pocas. Es una paradoja para pensarla aparte. Pero esta paradoja tal vez nos enseñe algo: que a veces también queremos ponerle un límite a la actividad economizadora, pues nos hace ganar mucho, pero también nos puede hacer perder algo. En mis primeros tiempos como programador encontraba mucho placer en tener la totalidad de un sistema en la cabeza: cada variable, cada procedimiento (estoy hablando de Pascal). Me gustaba incluso leer un programa de cabo a rabo y tratar de mantener las bifurcaciones posibles en la cabeza, para ver si el sistema soportaba todos los acontecimientos posibles. No se si esta es una conducta normal en un programador incipiente, si es propia de la juventud, o que, pero hace rato que encuentro placer en algo totalmente opuesto: que lo que hago descanse sobre bases que no hay que conocer en detalle, o al menos, si alguna vez conocí los detalles, que haya un punto en que es posible olvidarlos. Precisamente, el trabajo a partir de tests permite, si no olvidar los detalles, poder hacer funcionar la mente de tal forma que los detalles puedan ser olvidados temporariamente, pero que ante la necesidad de conocerlos, poder recuperarlos, hacer un "load", tal vez mandando a otra página los aspectos de más alto nivel, trabajar sobre esos detalles, para finalmente volver a liberar la mente y seguir adelante con el objetivo inicial. Cada vez que descubro que por haber cambiado un detalle se produce un impacto no deseado y que este descubrimiento no fue producto de tener todo el código en mi cabeza, si no una simple luz roja me maravillo: los tests me están ayudando a economizar, no el código, si no mi propia actividad mental. Creo que las falencias achacables al trabajo con test no tienen que ver con la idea subyacente a esta metolodogía, si no más bien con las limitaciones que tienen las herramientas que utilizamos. Señalo sólo una, para no hacerla tan larga. Dado que los tests son una especie de registro de la actividad del sujeto sobre un determinado dominio, es imprescindible que ese registro tenga no sólo un ordenamiento temporal, si no también un ordenamiento lógico, un ordenamiento de los más simple a lo más complejo. Supongamos el test más boludo del mundo: asignación y verificación de la asignación, es decir, un setter y luego un getter que devuelva el objeto seteado. Si bien hay casos en que esto no es trivial, en la mayoría los casos lo es. No obstante, me ha pasado que el browser se me tare y me modifique las variables asignadas. Es claro que si este test falla, todos los demás deberían fallar y todos estos fallos son triviales, pues dependen de un único fallo básico. Con las herramientas que utilizamos normalmente no hay forma de detectar que es ese test básico el que está fallando. Yo uso un método muy pedorro que no recomiendo a nadie, pero que a mi me sirve: numero los nombres de los métodos tratanto de mantener así el órden lógico. A la espera de algo mejor. Despues de tanto bla bla, un poco de código. Hace un tiempo hice una ampliación del TestRunner de Squeak para suplir alguna de las falencias de las herramientas de test. Es algo bastante primitivo porque para hacerlo bien hay que modelar muchas cosas que no están modeladas en Squeak (las categorías de clases y métodos, por ejemplo) . Este es el script de instalación (tiene que estar el último Installer cargado) | url | url:=url:= 'www.squeaksource.com'. (HTTPSocket httpGet: ' http://swikicaicyt.homeip.net/WebOpus/uploads/ProgressBarMorph.st') readStream fileIn. (HTTPSocket httpGet: ' http://swikicaicyt.homeip.net/WebOpus/uploads/ProgressMorph.st') readStream fileIn. (Installer monticello http: url ) project: 'CoverageTestCase'; install: 'CoverageTestCase'. Luego hay que hacer TestFanRunner initialize. TestFanRunner open. (Para que aparezcan los tests propios tiene que ser subclases de CoverageTestCase) Está también en la página nuestra ( http://www.caicyt.gov.ar/letodoc/paquetes-publicados) pero aún no hay ninguna documentación. Saludos Norberto --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
