QUnit advertises itself on its web page like this:

...capable of testing any generic JavaScript code, including itself!

Can you really use unit testing software to test itself? Wouldn't defects in the software mean that the results are unreliable?

  • 2
    Is this really a problem that you're looking to solve? Or are you looking to start a debate about theory? – Jim G. Aug 20 '12 at 16:45
  • 8
    @JimG. I'm pretty sure this question has a definitive non-debatable answer. – JJJ Aug 20 '12 at 16:46

Yes, it can. JUnit has an extensive test suite to test its own features, and ask any of the authors you like - they will tell you that this is essential to their productivity in extending the project. Probably most testing tools do the same.

The trick is that there is no particular need for a test of a new feature to be actually using the new feature itself - it merely has to exercise it and test the result. In this way, confidence in part of the functionality of a system can be used to establish confidence in a much larger part. This is similar to the way self-hosting compilers are bootstrapped, and it is a fundamental technique in computing theory.

  • The very example of writing a testing framework using tests is covered in the excellent book 'Clean Code' – CaffGeek Aug 20 '12 at 18:26

Kent Beck's book "Test Driven Development By Example" does precisely this: as an example of TDD he bootstraps a test framework that right from the beginning is used to develop itself.

  • maybe this is the book I meant to reference, not Clean Code...too many books, to little memory. – CaffGeek Aug 20 '12 at 19:51
  • 1
    +1 for bootstraping which is just as relevant to test frameworks as it is to compilers, see also dogfooding. – Mark Booth Aug 21 '12 at 13:30

You are correct, defects in the software do mean that the results are unreliable. However, there is a way to work around it, and build a reliable suite of tests.

The idea is to build a small testing harness that tests the very basic "core" functionality of each component of the testing system (usually, it consists of at least a framework and a runner). If testing framework is flexible enough, you should be able to plug that harness straight into your system, for example, by implementing an interface or by providing a required set of methods in the implementation of your harness.

The rest of the functionality should be tested relying solely on the "core" functionality, which is already tested using the harness. If you take care of using only the functionality from the "core" to test the non-core functionality, you would have a set of tests that you can trust.


I don't know about qunit, but I have worked several projects where previous versions of a solution were used to validate later versions so I don't view it as an invalid approach.

Any unit test package in a vacuum with not integration or UAT testing is going to be susceptible to a flaw in the test package itself as well as all the usual integration issues a unit test suite cannot cover so I am not certain I would even go as far as saying self testing on the same version is any more flawed than trusting new unit tests in any other project.

From briefly reading the project's linked site it more sounds like they are pointing out that there is nothing special case about the test scenario or the targets you can test than they are advertising that a self testing library is a perfect solution.


No you can't test software with itself, at least not in a way that would be acceptable in an audit situation. Independent verification has become a well established norm because it is far less likely that two different X(people, frameworks, tools) will both make the same mistake/ have the same bugs. This doesn't guarantee that whatever you test is actually correct, but it does mean there is a lesser chance of incorrectly passing any test. Testing something with itself can't actually increase your confidence that it works correctly, but it can be useful as a quick and dirty check to reduce the time it takes to receive feedback.

  • You do realize that tests should test both success and failure cases? Also typically when you test a testing framework with itself you should be using a "known good" version of the framework. I would only use a "develop" version of a testing framework as a final acceptance test before going to release. – binarycleric Aug 20 '12 at 22:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.