> 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.
