Not Found error when testing namespace

[devth]

I'm trying out vim-iced on my project, using https://github.com/yetibot/yetibot.core/blob/master/test/yetibot/core/test/commands/render.clj as an example test.

I'm using the default key mappings.

1. I try <Leader>tn and it givevs me Not found.
2. I try <Leader>tt on line 10 (or any line) and it gives me No test vars.
3. I try <Leader>rcn to clean and unexpectedly it removes my [yetibot.core.commands.render :refer :all] require, which is the ns under test. Not sure why?

I can <Leader>eb or <Leader>eB and those both work.

[liquidz]

@devth Thank you for reporting! vim-iced expects test files that namespace named "*-test" currently. So I'll fix to work tests without "-test" namespaces.

[liquidz]

@devth I fixed behaviors for <Leader>tn and <Leader>tt in dev branch. Could you test it?

I try rcn to clean and unexpectedly it removes my [yetibot.core.commands.render :refer :all] require, which is the ns under test. Not sure why?

This is the problem of refactor-nrepl. vim-iced is just using refactor-nrepl's clean-ns operation. Probably it is the cause that yetibot.core.commands.render/render-cmd is not called from yetibot.core.test.commands.render directly.

I can confirm that adding (comment (render-cmd {})) to the bottom of test codes avoid to remove it, but ... I have no idea for the fundamental solution.

[devth]

I verified it works! Thanks for the quick fix!

I noticed when I first run <leader>tt there is a slight delay that locks up my neovim for a few seconds. After the initial run the delay is gone.

Makes sense regarding clean-ns thanks for explaining.

[liquidz]

I noticed when I first run tt there is a slight delay that locks up my neovim for a few seconds. After the initial run the delay is gone.

@devth Thank you for the verification! <Leader>tt evaluates ns form internally, so it seems to take times for requiring the current namespace. Is the delay gone by running <Leader>eb (:IcedRequire) before <Leader>tt?

[devth]

Yes. But when I run <Leader>eb the delay is quite long, about 10 seconds. During this time NeoVim is completely locked up. Since nvim is async I would expect this to happen in the background instead of locking up.

[liquidz]

@devth Hmm.. <Leader>eb works asynchronously. It may be another problem. Could you open another issue?

[devth]

Certainly

[liquidz]

closed by #84