I broadly agree that tests should be part of the patch acceptance criteria for core kernel features. That's a no-brainer these days and with kunit it's not even that hard to write kernel unit tests.

I will say that there are a fair few test/fuzzing suites for the kernel (xfstests, selftests, kunit, the Intel 0day finder, syzcaller, etc). The last two I would argue are probably more likely to find exploits than unit and integration tests. There also has been a push in recent years to have better test frameworks for the kernel. (The reason I'd like more integration tests is because sometimes new kernel functionality is added without a strong enough specification of what it's behaviour should be -- writing tests tends to cause people to consider those corner cases.)

However one issue is that the vast majority of the code in the kernel is for drivers. It seems to me that it'd impractical to even attempt to mock hardware (since drivers also have to work around hardware bugs), so you'd only be able to do fairly rudimentary unit testing for the bulk of the code in the kernel. Modern websites don't have embedded drivers.