Yes, this is a know technique that is valuable for getting more relevant test results more quickly. The mild drawback that only selecting possibly-affected tests makes the test result more fragile can be avoided by merely using this information to determine the order of tests. That makes it likely that test failures will be reported quickly, while still having to run the full test suite before the tests are marked as passing.
However, this requires that you have per-test coverage data, and a test runner which can use this coverage data. Toolchains that can pull this off are quite rare, especially in the open source world. As in: I know of no such tools that actually implement this. Depending on the granularity you use for the coverage (e.g. per test versus per test suite, or per line versus per function coverage) this can also require a significant amount of storage.
Finally, there is the practical problem that many changes to the source code will not allow you to tie this change to the correct tests. For example, changing the control flow to execute additional code will not find the tests for this additional code. Worse, changing code that is not executed at run time and therefore has no coverage (like type declarations) has far reaching effects but will not select any tests.
In practice, what most test suites do is to organize the tests by the code they cover. Tests for
class Foo are in
FooTest. This association makes it unnecessary to have coverage data. Tests might also have tags to allow certain kinds of tests to be included/excluded. That might allow a user to manually select a suitable test subset such as
test (FooTest or BarTest) and not #slow. That is what I do to deal with slow-ish test suites. With appropriate care, a selection could also be made by a script.