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.

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.

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.