QUnit si pubblicizza sulla sua pagina web in questo modo:
...capable of testing any generic JavaScript code, including itself!
Puoi davvero usare il software di test delle unità per testare se stesso? Non ci sono difetti nel software significa che i risultati non sono affidabili?
Sì, può. JUnit dispone di un'ampia suite di test per testare le proprie funzionalità e chiedere a tutti gli autori che ti piacciono: ti diranno che questo è essenziale per la loro produttività nell'estendere il progetto. Probabilmente la maggior parte degli strumenti di test fa lo stesso.
Il trucco è che non vi è alcuna necessità particolare per un test di una nuova funzione di utilizzare effettivamente la nuova funzionalità stessa - deve semplicemente esercitarla e testare il risultato. In questo modo, la fiducia in una parte della funzionalità di un sistema può essere utilizzata per stabilire la fiducia in una parte molto più ampia. Questo è simile al modo in cui i compilatori self-hosting sono bootstrap, ed è una tecnica fondamentale nella teoria dell'informatica.
Il libro di Kent Beck "Test Driven Development By Example" fa proprio questo: come esempio di TDD, avvia un framework di test che, fin dall'inizio, viene utilizzato per svilupparsi.
Sei corretto, i difetti nel software significano che i risultati non sono affidabili. Tuttavia, c'è un modo per aggirarlo e creare una suite affidabile di test.
L'idea è di costruire una piccola strumentazione di test che collauda la funzionalità di base "core" di ogni componente del sistema di test (di solito, consiste di almeno un framework e un runner). Se il framework di testing è sufficientemente flessibile, dovresti essere in grado di collegare direttamente tale harness al tuo sistema, ad esempio implementando un'interfaccia o fornendo un set obbligatorio di metodi nell'implementazione dell'imbracatura.
Il resto della funzionalità dovrebbe essere testato basandosi esclusivamente sulla funzionalità "core", che è già stata testata utilizzando l'imbracatura. Se ti occupi di utilizzare solo la funzionalità del "core" per testare la funzionalità non core, avresti una serie di test di cui ti puoi fidare.
Non so qunit, ma ho lavorato a diversi progetti in cui sono state utilizzate versioni precedenti di una soluzione per convalidare versioni successive, quindi non la vedo come un approccio non valido.
Qualsiasi pacchetto di test unitario nel vuoto con integrazione o test UAT sarà suscettibile a un difetto nel pacchetto di test stesso così come tutti i soliti problemi di integrazione che una suite di test unitari non può coprire quindi non sono certo che lo farei arrivano persino a dire che l'autodiagnosi sulla stessa versione è più difettoso che fidarsi dei nuovi test di unità in qualsiasi altro progetto.
Da una breve lettura del sito collegato al progetto sembra che stiano facendo notare che non c'è nulla di speciale nello scenario di test o negli obiettivi che puoi testare di quanto non facciano pubblicizzando che una libreria autodiagnostica è una soluzione perfetta.
No, non è possibile testare il software con se stesso, almeno non in un modo che sarebbe accettabile in una situazione di controllo. La verifica indipendente è diventata una norma consolidata perché è molto meno probabile che due diverse X (persone, strutture, strumenti) facciano lo stesso errore / abbiano gli stessi bug. Questo non garantisce che qualsiasi cosa tu collauda sia effettivamente corretta, ma vuol dire che c'è una minore possibilità di passare scorrettamente qualsiasi test. Testare qualcosa con se stesso non può effettivamente aumentare la tua sicurezza sul fatto che funzioni correttamente, ma può essere utile come controllo rapido e sporco per ridurre il tempo necessario per ricevere feedback.
Leggi altre domande sui tag unit-testing