Having the ability to take test data doesn't make it non-deterministic though. It just means that if user wants to test with a different set of data, there is no need to recompile the test. This could be helpful to test cases the test write didn't think about.
Again, unit tests are not meant to be babysat. They are intended to become a part of the codebase and be run against every proposed change to ensure the change doesn't break anything. The whole process is supposed to be fully automated. Imagine a KUnit test run for all tests that gets kicked off as soon as a patch shows up in Patchwork and the maintainers getting the test run results. If you can think of a test that the change author didn't for a new corner case, then you as the maintainer ask the change author to add such test. Or if some corner case comes up as a result of a bug then the new case is submitted with the fix. This is how unit testing is deployed in the larger software world. In the most enlightened places a change will not be accepted unless it's accompanied by the unit tests that offer good coverage for the possible inputs and code paths. A change that breaks existing tests is either incorrect and has to be fixed or the existing tests need to be updated for the behavior change.