I have a genuine question as to why we believe that writing code to test code is a good way to test that something works as it should.
It always seems a little odd to me that we have developers writing code, which they (in theory) write unit tests for, then testers come along and test the dev code, and then write automated testing code to test the dev code.
It feels like we put a lot of effort in to testing whether dev code is working by writing test code, but then how do we know that the test code is working? Is there a missing piece of the puzzle?
We rely heavily on the results of the automated tests to tell us whether something is not working as expected (as part of a regression test), but without even more code to test the test code, how do we know that we can rely on the test results. Just because something says that it has passed, is it reliable and can we believe it? After all, it seems to be quite common in my experience that automated tests fail but not always for genuine regression issues - timeouts, data issues, UI changes that have not been reflected, removed functions etc.
So how can we have confidence that the test code we write to test the dev code is any good and serves a useful purpose?
It might seem an odd thing to ask, but my mind does work in odd ways (I digress but when I was 8 we were told to write a story about a tank and I was the only person to write about a fish tank, not an army tank!!), so I usually end up thinking of things in a different way, and this bugs me. I’m not out to cause any arguments as to the benefits of automation - I just wonder how we can have any confidence in something that isnt tested itself, if that makes sense.
Thanks - I await responses with interest