¿Se puede usar el software de prueba de unidad para probarse a sí mismo?

QUnit se anuncia en su página web así:

... capaz de probar cualquier código JavaScript genérico, ¡incluido él mismo!

¿Realmente puedes usar el software de prueba de unidad para probarse a sí mismo? ¿Los defectos en el software no significarían que los resultados no son confiables?

Sí puede. JUnit tiene un extenso conjunto de pruebas para probar sus propias características y preguntar a cualquiera de los autores que le gusten; le dirán que esto es esencial para su productividad en la extensión del proyecto. Probablemente la mayoría de las herramientas de prueba hacen lo mismo.

El truco es que no hay una necesidad particular de que una prueba de una nueva característica realmente esté usando la nueva característica en sí misma, solo tiene que ejercitarla y probar el resultado. De esta manera, la confianza en parte de la funcionalidad de un sistema se puede utilizar para establecer la confianza en una parte mucho mayor. Esto es similar a la forma en que los compiladores de autohospedaje son iniciados, y es una técnica fundamental en la teoría de la computación.

El libro de Kent Beck "Test Driven Development By Example" hace precisamente esto: como ejemplo de TDD, inicia un marco de prueba que desde el principio se utiliza para desarrollarse.

Tiene razón, los defectos en el software significan que los resultados no son confiables. Sin embargo, hay una manera de solucionarlo y crear un conjunto confiable de pruebas.

La idea es construir un pequeño arnés de prueba que pruebe la funcionalidad "básica" muy básica de cada componente del sistema de prueba (por lo general, consiste en al menos un marco y un corredor). Si el marco de prueba es lo suficientemente flexible, debería poder conectar ese arnés directamente a su sistema, por ejemplo, implementando una interfaz o proporcionando un conjunto requerido de métodos en la implementación de su arnés.

El resto de la funcionalidad debe probarse basándose únicamente en la funcionalidad "central", que ya se ha probado con el arnés. Si se ocupa de usar solo la funcionalidad del "núcleo" para probar la funcionalidad no central, tendría un conjunto de pruebas en las que puede confiar.

No sé acerca de qunit, pero he trabajado en varios proyectos en los que se utilizaron versiones anteriores de una solución para validar versiones posteriores, por lo que no lo veo como un enfoque no válido.

Cualquier paquete de prueba de unidad en el vacío sin integración o prueba de UAT será susceptible a una falla en el paquete de prueba en sí mismo, así como a todos los problemas de integración habituales que un conjunto de prueba de unidad no puede cubrir, por lo que no estoy seguro de que incluso vaya hasta decir que la autocomprobación en la misma versión es más defectuosa que confiar en las nuevas pruebas unitarias en cualquier otro proyecto.

Al leer brevemente el sitio vinculado del proyecto, parece que están señalando que no hay ningún caso especial sobre el escenario de prueba o los objetivos que puede probar que anuncian que una biblioteca de autoevaluación es una solución perfecta.

No, no puede probar el software consigo mismo, al menos no de una manera que sea aceptable en una situación de auditoría. La verificación independiente se ha convertido en una norma bien establecida porque es mucho menos probable que dos X diferentes (personas, marcos, herramientas) cometan el mismo error / tengan los mismos errores. Esto no garantiza que lo que sea que pruebe sea realmente correcto, pero sí significa que hay una menor probabilidad de aprobar incorrectamente cualquier prueba. Probar algo consigo mismo no puede aumentar su confianza de que funciona correctamente, pero puede ser útil como un control rápido y sucio para reducir el tiempo que lleva recibir comentarios.