Bueno, Por lo general, hay tres tipos de pruebas. Pruebas unitarias, pruebas del sistema y pruebas de control de calidad. Las pruebas unitarias, como su nombre lo indica, prueban unidades pequeñas: funciones y clases separadas.
Para todos los entornos de desarrollo modernos, existen marcos de pruebas unitarias. Hay Nunit para .net, así como el marco de prueba de unidades MS en Visual Studio, CPPUnit para C++, JUnit, etc. Todo por una cosa: conectarse a partes de su programa, ejecutar sus scripts predefinidos e informar de errores.
CPPUnit, por ejemplo, se basa en macros como CPPUNIT_ASSERT_EQUAL, destinado a ser utilizado como algo como esto: CPPUNIT_ASSERT_EQUAL (sum (arr), 17). Y diría si no es igual, en cuyo caso la prueba se considerará fallida.
Se supone que debe desarrollar las pruebas para cada función, y después de eso, no tiene miedo de cambiar y optimizar el código. En general, se lo denomina "repetibilidad": capacidad de realizar una acción compleja, como una prueba completa de toda la base de código, con un solo clic.
Se requieren pruebas unitarias para cada desarrollo de software moden, porque la experiencia demuestra que mejoran la velocidad de desarrollo. También se sugiere que el código de prueba unitario pueda servir como una especie de "documentación" para la biblioteca.
Las pruebas del sistema son pruebas automatizadas de mayor funcionalidad de alto nivel. La idea de las pruebas del sistema es proporcionar una entrada limpia (como bases de datos, entradas del usuario, etc.) para probar todo, validando la salida contra los resutls predefinidos.Es esencial que la salida del sistema sea determinista y solo depende de la entrada. Cada vez que el sistema cambia, las pruebas del sistema también cambian.
TDD es una mala idea que suena bien, lo que sugiere que no debe desarrollar nada antes de implementar las pruebas automatizadas adecuadas y luego escribir el código para satisfacer las pruebas. Se considera como una falla, porque los cambios en el diseño son inevitables durante el desarrollo, y un pequeño cambio de diseño generalmente causa cambios drásticos en las pruebas unitarias.
Manual QA es el último y más importante tipo de prueba de software. La idea es preparar un plan de prueba, que se realiza durante las fases de diseño y codificación, recopilar todas las ideas que los desarrolladores tuvieron durante la codificación de cada sentencia if, cómo hacer que esta instrucción if particular se ejecute a lo largo del camino del código menos esperado. El personal de control de calidad, diseñado para ser capaz de hacer todo lo que se pueda con el programa sin un entorno de desarrollo, puede seguir el procedimiento de prueba resultante y sus propias ideas, para encontrar más errores.
Algo no está claro aún. ¿Dijiste que cada vez que construyo mi código, la prueba de unidad debe pasar? Esto significa que debo escribir una función para probar mi función de suma, y esta función de prueba debe llamar a mi función de suma cada vez que se ejecuta mi aplicación. – RHaguiuda
Bueno, sí y no :) Por lo general, tiene dos configuraciones de compilación de algún tipo: 1. llamémoslo configuración de depuración. Esta es compilación con símbolos de depurador completos y se usa durante la codificación. En esta configuración, realmente desea que su prueba unitaria se ejecute cada vez que compile. La segunda configuración sería una configuración de lanzamiento. En esto no haces ninguna prueba de unidad y también dejas los símbolos de depuración y habilitas todas las optimizaciones en el compilador. – GorillaPatch
Gracias por ayudarme. ¿Puedes publicar algunos ejemplos aquí, por favor? (prueba de código y unidad). – RHaguiuda