Apology accepted, and I'll apologize as well. Your comment came off as short and argumentative, and I was tired. I'm sorry for that.

In terms of  TDD and implementing this. I'm not a huge TDD fan, often because people write tests for a thing (x or y), but they may end up with code that's slightly orthogonal to the item. I prefer to actually write tests that look for the issues I get. TDD and tests don't prevent bugs in software. They ensure that software passes the tests. If the tests aren't relevant, or don't test the functionality, then you can still have bugs.

However,  bugs in  software are separate from testing. Testing can improve the quality of software, but you need to write the tests that look for the bugs. For example, I wouldn't necessarily test this:
select  sum (notnullcolumn_x) from mytable
Why? It's a simple function, and I believe SUM() works. If I need to handle NULLs somehow, I might, but overall, I can't worry about this not working. However, COALESCE is more complex, and because I could get it wrong, or forget cases, I would write the test. If I need to ensure a non-trivial, multi-row result set, a test is good. The example I chose doesn't prevent bugs (as you pointed out with the period case), but it does ensure that I pass the cases I've added. If I add additional cases, I can improve the test. If I change the code, my test at least ensures I don't create regressions.

Adding testing to a project may or may not help. Your developers need to learn how to write tests. If  bugs still slip through, they aren't testing the things they should.