domingo, 30 de septiembre de 2012

11va Cocción: Porter - Resultados

En principio voy a decir que por un momento estuvo a punto de terminar por el drenaje.
El tema es que fermentó casi dos semanas, normalmente. Por esos días estuvo fresca la cosa, así que no había problemas. El fermentador cilindrocónico estaba en la casa de mi abuela, je, y el termostato exterior siempre marcó unos 18, 19°.

Terminadas las dos semanas, purgué las levaduras, y de pasó tomé una muestra. El refractómetro marcaba unos 7.6°Brix, lo que da una densidad final de 1016 gr/l.

Según cálculos tenemos una atenuación aparente de ~67%, que me suena algo baja, pero bue.. nunca usé esta levadura.

Quedó una cerveza de 4.6% de alcohol.

De gusto y aroma en ese momento, parecía todo bien. Se sentía bastante fuerte el amargo del lúpulo, y bastante cargado también el sabor a maltas torradas. Tipo un café. Por momentos me hizo acordar a la brown ale, que sacamos como segunda cocción de la imperial stout.
En realidad mi idea inicial era no abusar de las maltas oscuras, quería una cerveza un poco más dulzona, con más énfasis en las maltas caramelo y brown. Pero bueno, dije, todavía está verde, hay que esperar que madure.

Entonces, como no tengo forma de refrigerar el fermentador todavía, se me ocurrió llevarlo así como estaba al fondo, al quincho, a fín de que con el frío al menos decante un poco más.

Y así estuvo una semanita más. El tema es que justo, los dos últimos días, jueves y viernes, hizo un calor heavy.
Y cuando fui a embotellar el viernes, tomé una prueba... mmmm.... horrible. Ese sabor feo asidrado, a manzana.
Confirmo entonces que es debido a los alcoholes superiores.

Indignado, me decidí a embotellar de todas formas, porque ya había lavado todas las botellas. Y a rezar, obviamente al dios cervecero.

Luego de casi dos semanas en botella, este viernes detapé la primera que me traje a casa, y oh sorpresa !! No estaba para nada mal!
Si bien por momentos sentí un poquito de ese aroma asidrado, fue solo por momentos. En general el aroma y el sabor están bien. Sigue dejando un retrogusto amargo del lúpulo, que se acentúa con el sabor torrado o quemado de las maltas oscuras. Pero es mucho menor. Es decir, que de a poco se va a ir fusionando el sabor y disminuyéndo el desbalance de amargor (espero).

Voy a ver si compro algún exponente del estilo en el super, tipo la de Antares, para comparar.

Dejo acá un par de fotitos.

Saludos!






lunes, 24 de septiembre de 2012

Construyendo un sistema de refrigeración del fermentador cilindrocónico (Parte 1: La idea)

La idea

Construir un sistema de refrigeración para el fermentador cilindrocónico. Para qué ? para poder controlar la temperatura con buena precisión (como dios manda).
Porque estoy podrido. En verano sin refrigeración es imposible cocinar. Pensar que ya con una temperatura ambiente de unos 20 peligra la fermentación. Porque cuando la levadura está en actividad, es decir consumiendo los azúcares y reproduciéndose, genera calor.
Depende de muchos factores, pero el punto es que la temperatura dentro del líquido, podría estar como unos 4° por encima de lo que mide un termómetro por fuera.
Algunas levaduras toleran mejor las altas temperaturas y hasta generan ciertos aromas y gustos deseados. Por ejemplo las belgas. Hay cervecerías trapistas beglas que llegan a fermentar como hasta los 32°. Pero claro, los tipos tienen una cepa de levadura propia, que usan hace décadas, y que viene "entrenada", y acostumbrada a esas temperaturas.

Igualmente, fuera de las belgas, (casi) todas las demás levaduras se llevan horrible con las altas temperaturas. Generan lo que se llaman "alcoholes superiores", que se sospecha que es uno de los agravante/causantes (?) del dolor de cabeza del día de la resaca. Y generan otros aromas y sabores no deseados.
En general, la temperatura de fermentación debería estar entre los 17 y 21° para una levadura "ale".

El tema es que, cuando usaba los fermentadores de tipo sparkling, los metía en una heladera vieja, con un termostato que la encendía y apagaba automáticamente.
Pero ahora con el fermentador cilindrocónico, es imposible, por el tamaño.
Y quiero seguir usándolo, porque es mucho más cómodo, porque:
  • uso un solo fermentador -> menos cosas para limpiar
  • permite purgar las levaduras por abajo -> evita el transvase (que requiere limpiar y otro fermantador extra, además de incrementar las posibilidades de contaminación).
  • podría llenarlo hasta los 40 y pico de litros, que requeriría unos 3 fermentadores de 20 (por el headspace: espacio de aire que hay que dejar para que no desborde todo al diablo).
 El problema entonces con este fermentador es cómo controlar la temperatura.

Tipos de refrigeración

Seguramente haya infinitas formas de implementar esto. Pero las más comunes que vi yo fueron básicamente estas:

  • Externas:
    • Construir una minicámara con material aislante, e instalarle un aire acondicionado. Esto queda completamente fuera de mi alcance, por temas de espacio y porque tampoco pienso gastar una fortuna. Haría eso si estuviera encarando un negocio, pero no para hobby.
    • Camisa exterior: lo que hacen algunos es construir una camisa exterior al fermentador, que se llena con líquido refrigerante, que entra y sale, a un banco de frío mediante una bomba, supongo. El problema con esto es que no es lo más eficiente, ya que la pared de plástico no transmite el frío demasiado bien. Además, la refrigeración sería de afuera hacia dentro. En fín, no se mucho al respecto, pero vi no era nada fácil construir eso sin que perdiera por todos lados.
  • Interior/inmersión:
    • serpentina con líquido refrigerante: esta opción es mucho más eficiente que la camisa exterios, aunque las desventajas es que requiere luego limpieza de la serpentina, por ejemplo.
Mi conclusión fue que lo más fácil y lo mejor era hacer la serpentina interna.

Sería algo así como este dibujo que tomé prestado:



Aunque, imaginen que la serpentina va a estar dentro del fermentador, sumergida.
Y, el banco de líquido refrigerante estará dentro del freezer. Además, no sería de agua y hielo, sino de un líquido refrigerante especial, llamado glicol, a fín de que no se congele a temperaturas menores a 0°.

Además, usaría un controlador de temperaturas que tendrá el termostato midiendo la temperatura del fermentador. Y estaría programado para activar/desactivar la bomba automáticamente cuando se exceda la temperatura programada.
Acá está el controlador que tengo:

Quedaría algo asi, como tiene armado este flaco:


De hecho tiene el mismo controlador (ETC1000), una bomba similar (abajo en el medio), y el mismo fermentador.

Esto es todo por ahora.
En próximos posts voy a ir contando las peripecias de la construcción.

Referencias y detalles de materiales
  • Serpentina 
    • Caño de 3/8
    • Acero inoxidable.
    • Doblarlo no es para nada fácil. Llenar de arena (?)
  • Bomba
    • 1/2 HP
    • no hace falta que sea sanitaria (el líquido no se toma)
  • Aislante
    • Para que no le afecte tanto la temperatura exterior (especialmente en verano).
    • Sería bueno que se pueda sacar fácilmente.
    • Que no afecte la limpieza
    • Se usa aislante para techos de aluminio.
  • Refrigerante
    • con agua o con agua y alcohol pero al líquido lo trabajan siempre rondando los 0ºC
    • el alcohol puro a -20ºc es un éxito, sigue siendo tan líquido como a temperatura ambiente pero…, en caso de fuga, a temperatura ambiente es inflamable.
    • ETILENGLICOL

domingo, 23 de septiembre de 2012

Llegaron los libros

El viernes al mediodía llegaron los libros cerveceros. Creo que demoró menos de una semana el envío, ja !

Acá hay algunas fotos





The Brewmaster's Table parece el más zarpado, en todo: tamaño, diseño, contenido. Tiene muy buen arte, con fotos, y los estilos de tipografía, colores, etc, son muy buenos.
Después, Extreme Brewing también tiene una tapa pseudo-dura. Lo malo (bueno?) es que es bastante ancho y alto. Ambos los veo difíciles para leer en el bondi :(
El diseño de ext.br. también está muy bueno.

Los otros 3 son libros más tradicionales. Más chiquitos, lo cual es bueno para leer en el viaje.
Brewing Classic Styles es básicamente un libro de recetas. Tiene algunos capítulos más, pero en sí son recetas.

Scotch Ale parece bastante completo. Tiene una parte de historia del estilo. Luego secciones por cada componente. Por ejemplo, describe el agua de Escocia, maltas, levadura, etc. Tiene también recetas, claro. Y hasta tiene dos apéndices interesantes para quien piensa en algún momento hacer un tour cervecero por Europa en algun moment. El primero es de breweries, es decir cervecerías de Escocia. Y el segundo es de pub's de Edimburgo.

Por último Barley Wine, que es de la editorial Brewer's Publications (al igual que Brewing Classic Styles). Es el libro más chiquito de los que compré, fácil de leer. También tiene primero una sección con la historia, y comparación con otras big beers. Luego describe el perfil, sabor, color, amargor, alcohol, etc. Después los elementos también (agua, malta, lúpulo, etc). El proceso, que debe estar interesante. Recetas, y un par de apéndices.

Creo que voy a empezar con éste último, Barley Wine, porque es fácil de leer en el colectivo, y porque ya desde hace bastante que hablábamos de hacer una cerveza de éstas. Así, capaz en unos meses se viene la cocción. Aunque para eso supongo que deberé terminar el sistema de refrigeración del fermentador cilindrocónico (estoy haciendo otro post), porque se va a venir el calorcito.

Eso es to-to-to-to-todo amigos














miércoles, 19 de septiembre de 2012

10 Reasons to Fix Software Bugs Right Away

Tomo prestado esto que me pasaron en el trabajo y me pareció muy interesante.

  1. Unfixed bugs camouflage other bugs
  2. Unfixed bugs suggest quality isn’t important
  3. Discussing unfixed bugs is a waste of time
  4. Unfixed bugs lead to duplicate effort
  5. Unfixed bugs lead to unreliable metrics
  6. Unfixed bugs distract the entire team
  7. Unfixed bugs hinder short-notice releases
  8. Unfixed bugs lead to inaccurate estimates
  9. Fixing familiar code is easier than unfamiliar code
  10. Fixing a bug today costs less than tomorrow

jueves, 13 de septiembre de 2012

La deliberada estupidización del mundo

Con esto de las manifestaciones de hoy, y las discusiones que estuve leyendo en una lista de la que soy parte, que tiene, en su mayoría, como miembros, a graduados, estudiantes y/o profesores/ayudantes de materias universitarias, me quedé pensando bastante. Aunque ya anticipo, con ninguna conclusión o reflexión brillante. De hecho, todavía un poco perdido. Por eso escribo a ver si bajo un poco a algo concreto.

Aclaré el perfil del miembro de la lista, no en vano. Una de las cosas que más me llamó la atención en las discusiones sobre medidas económicas, políticas, etc., fue la falta de argumentación y de bases históricas, en las personas que aún teniendo un nivel universitario, parecen no hacer un análisis más profundo. Digo, más profundo que la pura y única consideración de sus realidades individuales.

Dicho en forma cruda, veo que, iba a decir en las personas de mi generación, pero no creo que sea verdad, lo veo en generación anteriores (mis viejos, por ejemplo), y también en generaciones más chicas: una pobreza importantísima de capacidad de análisis de la situación actual. Cuando digo análisis, el primer tipo que se me ocurre es el análisis comparativo. Es decir, comparar por ejemplo cómo estamos hoy, contra los 90, en cierto aspecto a elegir.

Y mejor aún, sería que cada uno pudiera hacer el análisis de las medidas que se toman, teniendo como baackground comparativo, la historia. La historia de nuestro país. La reciente, pero además, la historia de los orígenes de nuestro país. Luego la historia de América.
Porque la historia se repite, justamente por la falta de análisis y de memoria.

Y creo que eso es lo que nos falta. Porque me incluyo.
Y creo que no es casualidad.
Es un producto, de alguna forma, de la formación cultural y educativa que tuvimos. Y producto de la misma sociedad.

Para citar un ejemplo. En el secundario siempre fui buen alumno, en el sentido de que tenía muy buenas notas, y nunca reprobé ninguna materia, por ejemplo.
Pero la realidad es que muy pocas cosas me quedaron de todos esos años.
Lo poco de historia que se, lo se porque hace unos años me empezó a interesar y me puse a leer por mi cuenta. En general la historia del tipo "revisionista". Galeano, Pacho O'Donnell, Piña, etc.

Veo que mucha gente de mi generación, ni siquiera pasó por eso. Con lo cual, probablemente no sepan el transfondo de nuestra historia. Por ejemplo, los motivos reales de la guerra de la triple alianza. El hecho de que Inglaterra necesitaba materia prima, algodón, para su industria. Motivo por el cual utiliza a los tres países latinoamericanos para invadir Paraguay, que no permitía el ingreso de productos extranjeros a fín de permitir crecer la industria nacional. Claro, así lo pagaron. En las guerras mataron a todos los hombres y niños. Y se destruyeron todas las industrias. Paraguya es ahora uno de los países más pobres de Sudamérica.

Cuántas otros episodios en la historia tuvieron que ver con el real motivo de la apertura de mercados para la saturación de productos de países más desarrollados, o con mayor capital como Inglaterra, luego Estados Unidos ???
Al final la historia no es tan dificil. Se repite. Porque las acciones se pueden entender en términos de la ambición por la explotación. Explotación de todo tipo de recursos: naturales, humanos, etc.

Volviendo un poco, pensaba que de alguna forma ese mismo sistema, nos ha estupidizado. Nos ha embrutecido.
Así como, es bien sabido que el norteamericano promedio es bastante bruto, al punto de no poder ubicar países con continentes, creo que nosotros también vamos por el mismo camino.

Y no tiene que ver con la clase social. De hecho, creo que la clase media es una de las más brutas. Y eso también tiene un motivo.
Porque, la cultura del neoliberalismo fomenta el consumo, que se basa en la diferenciación, y por ende en el individuo. Con la falsa liberta de elección. Elección del color de la ropa, por ejemplo.
El individuo de clase media, tiene acceso a muchísimo de ese bombardeo de consumismo, y una falta de educación de valores comunes. La vida es "su" vida, y su capacidad de elección, y lo que sucede a su alrededor, importa en cuanto a que puede ayudarlo a conseguir ciertos fines, o puede impedírselos.
Estos factores lo llevan a una forma de vida de aislamiento de la sociedad. Vive en la sociedad, pero limita al mínimo la interacción con ella. Pretende vivir en esa burbuja. Pretende ser ajeno a esa sociedad. Ajeno al gobierno, ajeno a los problemas de los demás -porque el ya tiene los propios que tiene que resolver-.

La realidad es que, la regla subyacente es la del "sálvese quien pueda", la ley de la selva.
Y nadie lo dice, pero gusta. Gusta que sea así.
Porque, de otro modo, no habría lugar para mezquinidades, e individualismos. Habría responsabilidades.
Pero también, me parece, se teme. Y tal vez, la gente sigue defendiendo este modelo, más por miedo que por real adherencia.
Me refiero a miedo a lo desconocido. Miedo a no saber cómo sería la sociedad si fuera de otra forma.
Cómo sería la sociedad si no existiera la estúpida idea de "dinero a cambio de trabajo".
Casi en la misma forma en que un religioso mantiene la fé en su Diós, por miedo a pensar un mundo donde sólo existe él, solo existen las personas y no puede acudir a esa entidad externa para explicar las cosas.

En ese sentido, el sistema neoliberal, también se parece bastante a la idea de una religión. Justamente por esto último que digo. Las religiones se basan en la proyección externa. En la creencia, o necesidad de la existencia de algo externo. De que, no depende de mí, sino de otra cosa.
De alguna forma, eso mismo ha logrado la educación en nuestra generación.
La gente proyecta. Se ve fuera de todo.
Por eso, me causaba gracia el zócalo de TN hoy durante la marcha, que mencionaba el hecho de que no había banderas de partidos políticos.
Eso, apoyo mi idea, del perfil de gente que se encontraba ahí. Que, repito, me incluyo. Víctimas de este tipo de educación y adoctrinamiento.
Ajenos a los partidos políticos. Ajenos a la política. Porque, además, pensamos eso, que la política es mala, es mafia, es sucia, es negociados.
Pero bueno, mientras no me jodan, que hagan lo que quieran. Total, soy ajeno a la política. Y además, proyecto: los gobernates deberían hacer tal o cual cosa. La presidenta es responsable de X. La inseguridad blah. "Y vos qué hacés para ayudar a que no sigan pasando esas cosas ?", "Ah no, yo nada, esa no es mi responsabilidad, para eso tenemos gobernates.". De nuevo él, "yo ya tengo mis problemas con mi laburo, mi familia, etc".
Hasta que me afecta.

Vuelvo un poco. Pensando en que esta estupidización no era fruto del azar, busqué un poquito en internet  y encontré esto, de donde tomé prestado el título:
http://teatrevesadespertar.wordpress.com/2011/10/19/charlotte-iserbyt-la-deliberada-estupidizacion-del-mundo/

Me gustaría leer el libro. Si bien parece una de esas cosas "new age" de conspiraciones, bien yankee, creo que se puede sacar algo en limpio, y en parte tiene coherencia con la realidad y lo que venía diciendo.

Me queda un tema por repensar, que es, contraponer esta nueva cultura individualista, con la la cultura de las comunidades originarias de nuestro suelo. Las famosas tolderías del sur, por ejemplo.
Cuántas veces vemos, incluso en documentales, cómo viven hoy tribus de países remotos, y nos admiramos de la idea de comunidad, y de bien común que tienen. De colaboración, ayuda mútua. Incluso de la diferencia con nuestra  estructura familiar "tradicional". Y cuántas veces nos quejamos de que en la ciudad todos se pasan por arriba unos a otros.
Pero por qué no podemos trasladar esos valores, a otros planos, a otras discusiones, al análisis de la realidad, de nuestro "modelo" de país.


Bueno, salió una ensalada de frutas !
A seguir pensando.



Bash scripting de la muerte


for i in `find -name pom.xml`; do grep "6.2.0" -qn $i; test $? = 0 && echo $i ; done

Java + Spring + Groovy

Breve.
Encontré un lindo post que muestra algunas formas de integrar java con groovy a través de spring.

http://groovy.codehaus.org/Embedding+Groovy

La que incluye el namespace "lang" y permite pasarle el script en .groovy, me parece una de las más útiles, cuando en una aplicación hecha mayormente en java, nos gustaría definir una interface tipo "punto de extensión", y que después uno pueda cambiar la impl rápidamente sin necesidad de recompilar, o generar un nuevo release.

Suele ser una buena forma de dejar la puerta abierta a poder solucionar un problema rápidamente cuando aparece en el campo y tenemos a todos los chupa-sangre encima para dar una solución "ASAP". Que es cuando resulta bastante dificil explicarles que hay que hacer un nuevo release, con su tag en svn, o que maven no se digna a funcionar, o blah.

Saludos!

miércoles, 5 de septiembre de 2012

Imposible revertir el efecto de la entropía...

...causada por la falta de test cases.

Es un poco mi conclusión. O bueno, la palabra conclusión suena muy ambiciosa. Porque tampoco es que pretendo concluir, no seguir reflexionando al respecto, o no cambiar mi opinión, en un futuro.
Pero es la sensación que me da, por el momento.

Que qué ?

Que es muy muy muy dificil, casi imposible, revertir la situación en la que un equipo de desarrollo se hace cargo de un producto mediano-grande/grande, el cual fue construido sin test unitarios, y llevarlo a un nivel de cobertura coherente.

Muchas veces escucho a la gente decir, en tales situaciones, u opinar desde afuera: "ah, pero entonces si hay código malo, hay que hacerle testcases". Y algunos agregan, ".. para luego refactorizarlo".
Suena muchísimo más simple de lo que parece.

Y mi conclusión, supongo que sonará algo controversial en un principio, hasta que me explique, es que es imposible, e impráctico hacer testcases en retrospectiva.

En primer instancia, porque, por naturaleza, el test asegura cierto comportamiento "esperado" del sistema. Entonces, generalmente uno parte del test, y luego implementa la lógica (como en TDD).
Pero si parto de la implementación, cómo se que lo que está haciendo es un verde ? Cómo se que es lo esperado ?
Ok, debería tener una especificación de requerimientos para eso. Pero también se da la correlación de que un sistema sin test unitarios, tampoco tiene especificación de requerimientos, o al menos una útil a tal efecto.

En segundo lugar, porque dicho sistema, suele tener un nivel de acoplamiento infernal, lo cual lo convierte en imposible de testear.
Pasa que uno nunca sabe por donde empezar. Es como cuando se te enreda uno de esos juegos que venden en retiro de piecitas de alambre. Y lo ponés sobre la mesa, y decís, por donde diablos tiro para deshacer esta maraña.

Porque, además, hay que entender que, por más que existen herramientas para encarar el testeo unitario en forma de concern transversal, es decir con aspectos, con frameworks de mocks. Se hace mucho más simple, si uno ya diseña el software, teniendo en cuenta la facilidad para testearlo.

El tercer punto, es que, un sistema caótico, codificado proceduralmente y con baja calidad, suele tener una cantidad de código mucho mayor a la realmente necesaria para implementar las mismas funcionalidades pero bajo las buenas prácticas (por ejemplo el principio DRY, el uso del polimorfismo, composición, herencia, etc).
Entonces, por qué querría perder tiempo testeando 80.000 lineas de código, de las cuales se que, al menos 60.000 están de más, y que, eventualmente van a desaparecer ? Porque, por ejemplo voy a reemplazar miles de lineas que parsean XML "a mano", por el uso de un fwk declarativo, como digester, o xstream.

Obviamente que entiendo la idea de que, el test me permitirá validar, al reemplazar ese código "feo", por el nuevo "prolijo". Verificar que el nuevo produce los mismos resultados que el viejo. Que es equivalente. Definición de refactor. Solo cambié la implementación.

Pero eso, nuevamente es teoría, fácil de decir, o repetir, simple y correcta en el caso ideal, pero que es muy dificil de que suceda en la realidad.

Porque, cuarto, un sistema de este tipo, justamente no tiene abstracciones, no tiene interfaces bien pensadas y diseñadas para separar sus módulos. De modo de que yo pueda hacer el test, y poder correrlo contra la implementación vieja, y la nueva.
Porque ahí sí, el test es todo ganancia. Luego de refactorizar, me seguiría sirviendo exáctamente así como está, para tener cobertura sobre la nueva impl.

Pero no, en la práctica, como decía, no se puede hacer un tests sobre el código viejo, que sirva para el código nuevo.

Entonces, es inevitable, hay que arrancar por refactorizar.
Yo no digo que no haya que hacer ningún tests. Lo que digo, es que la premisa, o el objetivo principal del programador, no debe ser el de hacer testscases. Debe ser el de refactorizar.
En el medio, en el trayecto, va haciendo testcases. Los que ameriten.
Cuando se pueda, empezará por un test, y luego refactorizará.
Pero cuando no, habrá que refactorizar, y luego pensar en el test.

Y en especial, dentro de la idea de refactorizar, me parece que el objetivo más importante del desarrollador, tiene que ser el de reducir la cantidad del código al mínimo.
Si logro bajar de 80.000 a 60.000 o a 40.000 lineas de código,  me resultará mucho más simple trabajar en la cobertura.

Obviamente que esta tarea es complicada, y creo que me gustaría reflexionar un poco más, para luego hacer otro posts específico dedicado a ese proceso de refactorizar un sistema que no conocemos.

Pero volviendo, creo que ese es el camino.
Al menos, de las experiencias de laburo que tuve, nunca vi que se haya podido revertir el nivel de cobertura, cuando este es muy bajo.
  • En un laburo partimos de un framework web con cero tests cases. Trabajamos casi 3 años en eso. Lo cambiamos rotúndamente, hacia un fwk mucho más declarativo, que generaba el html automáticamente, con aspectos para manejar transacciones a nivel de objetos, etc. Se intentaron varias estratégias para testearlo. Por ejemplo con tests automáticos con herramientas como selenium. Lo que pasó es que ante cambios mínimos, esos tests se rompían. Además, eran tests que requerian muchísimo esfuerzo de mantenimiento. Que además, tenían complejidad accidental, como que necesitaban abrir un browser iexplorer, etc. etc.. Eventualmente, el costo hizo que nadie le de bola. 
  • En otro laburo, trabajaba sobre un producto muy muy grande, que ya tenía como unos 6 años o más. Donde muchos de los desarrolladores originales ya no estaban. Una cantidad de código monstruosa. Lo mismo. Hubo muchos esfuerzos individuales de ir agregando un testcito por aquí, otro por allá. Luego, cuanto más trataba de abarcar el test, más era susceptible ante cambios, y más complejo de configurar, y mantener. A lo que, quizás el creador se iba a otro módulo o de la empresa, y el que venía atrás miraba el test rojo, y terminaba por comentarlo, borrarlo, blah.
  • En otro proyecto de investigación sucedía algo parecido. Incluso, no solo con la ausencia de tests, sino también por ejemplo, con la ausencia de un framework de dependecy injection. Es muy dificil cambiar una arquitectura así.
Ahora, nuevamente estoy trabajando en un producto de unas 80K lineas con 2.3% de cobertura. Y de nuevo, veo que intentar hacer tests es imposible:
  • los tests de aceptación o de integración, que por un lado tienen la ventaja de abarcar más, se tornan inmantenibles, y el impacto de esfuerzo ante refactors (que siempre van a suceder) es muy grande.
  • los tests bien unitarios, creo que representan algo así como intentar matar un elefante con una gomera y arbejas.
Como conclusión, el objetivo principal del programador debería ser, primeramente, el llevar el código a una unidad maleable, controlable. Luego eso, sí va a ser mucho más simple de testear y mantener.

Salió un posts mucho más largo del que esperaba.

Saludines !