Running a single test runs all tests containing the single test's name

[bpringe]

Mentioned in the Calva channel here: https://clojurians.slack.com/archives/CBE668G4R/p1682118654199809

If I have the following tests defined and I run the "Run current test..." command with my cursor on a-test, all three tests run.

(deftest a-test
  (println "running a-test")
  (is (= 1 1)))

(deftest b-a-test
  (println "running b-a-test")
  (is (= 1 1)))

(deftest a-test-b
  (println "running a-test-b")
  (is (= 1 1)))

We need to pass a regex here that matches the exact test name, I think. I tried doing this for a bit but couldn't get it to work as desired. search is a string, and I'm not sure exactly what is expected there by cider-nrepl/orchard. The docs for var-query are here. (The cider-nrepl docs point there.)

[bpringe]

@PEZ Could you take a look at this when you get a sec? I tried passing '^a-test$' but no tests are matched with that. I tried other things as well but couldn't get a match on just a-test.

[PEZ]

I notice that CIDER uses the op test, and not test-var-query as Calva does. Well, I'm not sure, but it looks like so here: https://github.com/clojure-emacs/cider/blob/master/cider-test.el#L670

Maybe @bbatsov can advice us some here? Or know who could.

[PEZ]

I now also tried to anchor the regex and it only resulted in no tests being found. I see that re-find is being used:

https://github.com/clojure-emacs/orchard/blob/master/src/orchard/query.clj#L77

But I haven't figured out where the search param is being turned into a regex.

[bpringe]

I notice that CIDER uses the op test, and not test-var-query as Calva does.

The test op is deprecated according to the cider-nrepl docs: https://docs.cider.mx/cider-nrepl/nrepl-api/ops.html#test

[bpringe]

But I haven't figured out where the search param is being turned into a regex.

That's happening in cider-nrepl here: https://github.com/clojure-emacs/cider-nrepl/blob/d219ce610d9030108c273fab933538fb3b24d8be/src/cider/nrepl/middleware/util/coerce.clj#L42.

re-pattern is used.

[bpringe]

I tried a couple of things that didn't work, but here are the nrepl logs for those tries:

Changed the test function to this:

  test(ns: string, test: string) {
    const search = util.escapeStringRegexp(`^${test}$`);
    return this.testVarQuery({
      'ns-query': {
        exactly: [ns],
      },
      search,
      'search-property': 'name',
      'test?': true,
    });
  }

-> sent
{
  op: 'test-var-query',
  id: '13',
  session: 'c80f2294-ae35-49c1-bc3b-c7c4a3b81fd1',
  'var-query': {
    'ns-query': { exactly: [Array] },
    search: '\\^a-test\\$',
    'search-property': 'name',
    'test?': true
  }
}

<- received
{
  'gen-input': [],
  id: '13',
  results: {},
  session: 'c80f2294-ae35-49c1-bc3b-c7c4a3b81fd1',
  summary: { error: 0, fail: 0, ns: 0, pass: 0, test: 0, var: 0 },
  'testing-ns': []
}

<- received
{
  id: '13',
  session: 'c80f2294-ae35-49c1-bc3b-c7c4a3b81fd1',
  status: [ 'done' ]
}

I also sent just ^<test>$ directly.

  test(ns: string, test: string) {
    return this.testVarQuery({
      'ns-query': {
        exactly: [ns],
      },
      search: `^${test}$`,
      'search-property': 'name',
      'test?': true,
    });
  }

-> sent
{
  op: 'test-var-query',
  id: '9',
  session: 'fea81bf3-cb9b-4748-8f59-5875845d64ea',
  'var-query': {
    'ns-query': { exactly: [Array] },
    search: '^a-test$',
    'search-property': 'name',
    'test?': true
  }
}

<- received
{
  'gen-input': [],
  id: '9',
  results: {},
  session: 'fea81bf3-cb9b-4748-8f59-5875845d64ea',
  summary: { error: 0, fail: 0, ns: 0, pass: 0, test: 0, var: 0 },
  'testing-ns': []
}

<- received
{
  id: '9',
  session: 'fea81bf3-cb9b-4748-8f59-5875845d64ea',
  status: [ 'done' ]
}

---

I'm not sure why ^a-test$ doesn't work, because using it directly with re-find and re-pattern does what we want.

  (re-find (re-pattern "^a-test$") "a-test")
  ;; => "a-test"

  (re-find (re-pattern "^a-test$") "b-a-test")
  ;; => nil

@bbatsov Any idea what we should be sending here, or who else we could ask?

[bpringe]

I suppose it's possible that the encoding is doing something to the string so that when it's decoded by cider-nrepl it's not actually the string we expect. Seems unlikely that's happening, though, since we don't usually (or maybe never) have encoding issues like that.