Falacia de la descomposición y la composición en pruebas de performance

Recordando lo que escribí alguna vez acá, también es aplicable al testing de performance.

Se tiende a creer que es suficiente con solo probar las unidades sin considerar la integración entre las unidades (falacia de la descomposición) y se tiende a creer que si a un sistema lo probamos como un todo, entonces también quedan por probadas cada una de las partes (falacia de la composición). En realidad no, el que probemos un sistema como un todo, no asegura que probemos el correcto funcionamiento de las partes individuales, y viceversa.

Me quería centrar en la falacia de la descomposición. Si hago pruebas unitarias de performance, cada unidad funciona perfectamente, incluso en concurrencia, o sea, varios hilos ejecutando esta misma funcionalidad al mismo tiempo. Claro está, que esto no garantiza que cuando se ejecuten varias funcionalidades diferentes al mismo tiempo todo seguirá funcionando con buena performance. Un ejemplo podría darse al hablar de dos componentes que acceden a las mismas tablas de la base de datos, que tal vez cuando los ejecute al mismo tiempo se bloqueen entre ellos a pesar de haber dado excelentes resultados al probarlos por separado.

Me pasó algo gracioso en Argentina, en el TestingAr, que al pedirle ejemplos de esto al público, alguien me dijo un ejemplo muy cómico: “la selección argentina, cada uno por separado son excelentes, pero al ponerlos todos juntos no funcionan tan bien”.

 

Leave a Reply

Your email address will not be published. Required fields are marked *