Unit testing for signal processing?

I came across similar problems like this one: Test driven development for signal processing libraries

The fact behind the problem is that the output of signal processing is hard to be fully and qualitatively defined.

So the inject input > run program > verify output approach does not apply well to signal processing.

Does meeting the performance requirement in the specifications mean that there's no bugs? Of course not. Then if it meets the requirement, why bother? Because bugs will bite, someday, they will.

In the end, the only feasible solution is to compare the output with a known-good equivalent, usually a matlab version or some widely used libraries.

Matlab has a good collection of libraries, and it has boundary checking, memory management, and it's double precision, so comparing with matlab code exposes pointer-out-of-bound, stack-overflow, and evaluates integer precision sufficiency, but it does not answer the question like "what if the matlab equivalent did it wrong, too?"

I can only say to myself: try to write the matlab equivalent simple, so it's close to "so simple that there's obviously no bug"

In my team, I have programmers at a variety of skill levels, and I need at least some kind of measure to control/enforce the quality of the code.

It's been more than two years since the last post. I with there are some new development in this area.

Please share with me, as practitioners, your ideas and opinions.