This was similar to the idea of using codeq to check which function change and run the test calling the function. Especially for pure functions it makes sense.

But yeah it would be great!

@aviflax I think you hit a pretty specific edge case, I wouldn't worry about it too much

Clojure is to some extent statically analyzable, that's what e.g. Cursive does, because functions generally are not polymorphic. In Ruby every method call is polymorphic, you never know what implementation gets called unless you know the runtime type. Clojure does have polymorphism as well though, through multimethods, protocols, interfaces, proxy/reify, so you have the same problem there. Plus we have macros. So in practice you only get so far with static analysis.

There's an alternative approach where you adopt conventions to make it clear which tests test a certain function, this is what Mutant does (https://github.com/mbj/mutant/blob/master/docs/mutant-rspec.md#test-selection). When you are doing mutation testing you need to be able to narrow down the number of tests to run, otherwise it becomes impossibly slow, so Mutant expects that you name your tests in such a way that it can determine which class/method is being tested. In Clojure we could use metadata for this.

(deftest ^{:test/subject #'my.example/some-fn} some-fn-test ,,,)

this is of course more limited than the call graph approach, in this case you won't get the tests that indirectly call some-fn. When you're doing mutation testing that's good though, because it forces you to test all functionality explicitly.

oh, interesting. Hadn’t really looked that hard into mutation testing.

(I also don’t have enough tests anywhere to really warrant that call graph business, though it might be interesting for longer-running tests like a cucumber browser suite).