Las pruebas unitarias, las pruebas de integración y las pruebas del sistema son difíciles. Las pruebas de rendimiento del software son más difíciles y, por lo tanto, a menudo se descuidan.
Las pruebas de unidad e integración generalmente se basan en una especificación o diseño, por lo que generalmente es sencillo: haga X y vea si Y es el resultado. Establecer métricas para las pruebas de rendimiento no es sencillo; ¿La configuración de prueba replica el “mundo real”, las métricas tienen en cuenta las diferencias en hardware y configuración, los datos de entrada replican el “mundo real”? Si se equivoca, la prueba puede generar fallas falsas en la prueba y falsas pasadas de prueba, lo que resulta en una falsa sensación de seguridad o una falsa sensación de pánico.
El santo patrón de la programación, Donald Knuth, dijo una vez: La optimización prematura es la raíz de todo mal . Knuth tenía un punto en el pasado cuando los programadores codificaban sus propias estructuras de datos y los algoritmos de búsqueda y clasificación y los ciclos de CPU eran productos que debían acapararse. Hoy en día, las cosas son diferentes.
- ¿En qué debería estudiar y centrarme, inteligencia artificial, desarrollo de software o seguridad cibernética?
- ¿Por qué las grandes empresas contratan a grandes ingenieros y les piden que hagan un trabajo mundano? ¿Por qué no pueden automatizarse estas tareas cotidianas, como las operaciones de desarrollo, utilizando IA?
- ¿Cuál es el error más grande que sucedió en su entorno de producción?
- Cómo medir el software de trabajo entregado diferente de contar Story Points entregados en un sprint
- ¿Cuáles son sus creencias principales sobre las pruebas de software?
La mayoría de nosotros hoy en día estamos usando una gran cantidad de frameworks, bibliotecas, herramientas y widgets que nunca nos permiten estar a una distancia de cualquier ganancia algorítmica teórica en velocidad o eficiencia. Ya nadie se preocupa por los méritos relativos de diferentes algoritmos de clasificación o búsqueda o estructuras de datos.
Por lo tanto, los peligros de la “optimización prematura” a menudo se traducen en “no tenemos que preocuparnos por eso ahora, lo probaremos más tarde”, excepto que las pruebas posteriores a menudo son fáciles de omitir.
Estrechamente relacionado con esa actitud es “no tenemos que preocuparnos por el rendimiento ahora, si tenemos un problema, simplemente le arrojaremos más memoria, disco y CPU”, gracias a la Ley de Moore.