O software de teste de unidade pode ser usado para o teste de unidade?

O QUnit se anuncia em sua página da web assim:

... capaz de testar qualquer código JavaScript genérico, incluindo ele próprio!

Você pode realmente usar o software de teste de unidade para testar a si mesmo? Defeitos no software não significam que os resultados não são confiáveis?

Sim pode. A JUnit possui um amplo conjunto de testes para testar seus próprios recursos e perguntar a qualquer um dos autores que você gosta - eles dirão que isso é essencial para a produtividade deles na extensão do projeto. Provavelmente, a maioria das ferramentas de teste faz o mesmo.

O truque é que não há necessidade particular de um teste de um novo recurso estar realmente usando o novo recurso - ele apenas precisa exercitá- lo e testar o resultado. Dessa maneira, a confiança em parte da funcionalidade de um sistema pode ser usada para estabelecer confiança em uma parte muito maior. Isso é semelhante à maneira como os compiladores auto-hospedados são inicializados e é uma técnica fundamental na teoria da computação.

O livro de Kent Beck, "Test Driven Development By Example", faz exatamente isso: como exemplo de TDD, ele inicializa uma estrutura de teste que, desde o início, é usada para se desenvolver.

Você está correto, os defeitos no software significam que os resultados não são confiáveis. No entanto, existe uma maneira de contornar isso e criar um conjunto confiável de testes.

A idéia é criar um pequeno equipamento de teste que teste a funcionalidade "básica" muito básica de cada componente do sistema de teste (geralmente, consiste em pelo menos uma estrutura e um corredor). Se a estrutura de teste for flexível o suficiente, você poderá conectar esse chicote diretamente ao seu sistema, por exemplo, implementando uma interface ou fornecendo um conjunto de métodos necessários na implementação do seu chicote.

O restante da funcionalidade deve ser testado, contando apenas com a funcionalidade "principal", que já foi testada usando o chicote. Se você se encarregar de usar apenas a funcionalidade do "núcleo" para testar a funcionalidade não essencial, terá um conjunto de testes nos quais poderá confiar.

Não conheço o qunit, mas já trabalhei em vários projetos em que versões anteriores de uma solução foram usadas para validar versões posteriores, por isso não a vejo como uma abordagem inválida.

Qualquer pacote de teste de unidade no vácuo sem integração ou teste de UAT será suscetível a uma falha no próprio pacote de teste, bem como a todos os problemas de integração usuais que um conjunto de testes de unidade não pode cobrir, por isso não tenho certeza de que iria tanto quanto dizer que o autoteste na mesma versão é mais defeituoso do que confiar em novos testes de unidade em qualquer outro projeto.

Ao ler brevemente o site vinculado do projeto, parece mais que eles apontam que não há nada de especial no cenário de teste ou nos alvos que você pode testar do que anunciando que uma biblioteca de autoteste é a solução perfeita.

Não, você não pode testar o software consigo mesmo, pelo menos de uma maneira que seria aceitável em uma situação de auditoria. A verificação independente tornou-se uma norma bem estabelecida, porque é muito menos provável que dois X diferentes (pessoas, estruturas, ferramentas) cometerão o mesmo erro / com os mesmos erros. Isso não garante que o que quer que você teste esteja realmente correto, mas significa que há uma menor chance de aprovação incorreta em qualquer teste. Testar algo consigo mesmo não pode aumentar sua confiança de que ele funciona corretamente, mas pode ser útil como uma verificação rápida e suja para reduzir o tempo necessário para receber feedback.