rcarriga / vim-ultest Goto Github PK
View Code? Open in Web Editor NEWThe ultimate testing plugin for (Neo)Vim
License: MIT License
vim-ultest's People
Contributors
Stargazers
Watchers
Forkers
ippachi jpserra ktakayama hiphish aerex timgent kedde mflova frederick888 megawubs georgeharker heynemann lessthanseventy pernambucano kexuzzzvim-ultest's Issues
Lazy loading buggy until opening summery window
Describe the bug
I'm a big fan of loading plugins lazy when they become necessary (e.g. I don't need this plugin until I actually want to run a test or for writing an email not at all).
But apparently this does not work. The plugin gets loaded and the commands etc are their. But if I run :Ultest or :UltestNearest, nothing happens. Silence. I added some debugging messages to the VimL stuff. And I can trace it down to this call where it switches to Python. In python I don't anything to print. No clue what is happening here. If I execute :echo call('_ultest_run_all', ['path/to/file']) it always just prints 1. So the plugin is loaded and it basically does something. Just that nothing happens...
When I open the summary window with :UltestSummary and then go to a test case and hit r to execute the case, it works. From now on I can also call :Ultest and :UltestNearest.
If I turn of the lazy loading of the plugin and always source it at startup, it just works and I can call :Ultest right away.
Logs should be created using ULTEST_LOG_LEVEL=DEBUG ULTEST_LOG_FILE=vim-ultest.log nvim <test-file> and added here as well
11:36:06 | INFO | MainThread | logging.py:create_logger:71 | Logger created
11:36:06 | DEBUG | MainThread | __init__.py:__init__:40 | Handler created
11:36:06 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:42 | Starting job with group run_all
11:36:06 | INFO | Thread-1 | __init__.py:run:101 | Running all tests in src/main.rs
11:36:06 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:57 | Finished job with group run_all
To Reproduce
This assumes that vim-test is always available in path (simplification for the moment of testing). So this is the packer.nvim configuration:
lua packer.use({
\ 'rcarriga/vim-ultest',
\ run = ':UpdateRemotePlugins',
\ cmd = {'Ultest', 'UltestNearest', 'UltestSummary'},
\ })Expected behavior
The plugin works after it got loaded and you can execute :Ultest.
Error “The input device is not a TTY” when used with Docker
I am getting this error when using Neovim Nightly (Lua) with PyTest via Docker. Moving my cursor over the title of the test throws out a box with "The input device is not a TTY"
My config is:
g['test#python#runner'] = 'pytest'
g['test#python#pytest#options'] = '--color=yes'
g['test#python#pytest#executable'] = 'docker-compose -f "./docker-compose.yml" exec -w /usr/src/app web pytest'
Configure mappings for the attach window
So far, loving the plugin! I haven't managed to make any other test plugin stick yet (including nvim-dap-ui) for various reasons, but this one seems the most ergonomic that I've tried.
Describe the bug
Is it either possible today, or possible to add customizations to the mappings used by the floating window on :UltestAttach?
Currently <c-c> in that window closes the window. Personally in these sorts of windows, i ctrl-c all the time, so this makes working with the window rather more difficult.
Expected behavior
I'd love to be able to run ctrl-d, like on a terminal, and/or a way to exit insert mode after you've entered it and just directly :q
Cannot run tests (pytest)
Describe the bug
I have a test file written in Python using pytest as the test runner. Whenever I execute :Ultest or :UltestNearest I get a Neovim error. Running the test with :TestFile or TestNearest however works fine. Here is the error:
error caught in async handler '/home/hiphish/.local/share/nvim/site-packages/vim-ultest/rplugin/python3/ultest:functi
on:_ultest_run_nearest [[0, 'test_pydantic.py']]'
Traceback (most recent call last):
File "/home/hiphish/.local/share/nvim/site-packages/vim-ultest/rplugin/python3/ultest/__init__.py", line 83, in _ru
n_nearest
self.handler.run_nearest(*args)
File "/home/hiphish/.local/share/nvim/site-packages/vim-ultest/rplugin/python3/ultest/handler/__init__.py", line 14
8, in run_nearest
self._runner.run(
File "/home/hiphish/.local/share/nvim/site-packages/vim-ultest/rplugin/python3/ultest/handler/runner/__init__.py",
line 46, in run
self._run_group(tree, file_tree, file_name, on_start, on_finish, env)
File "/home/hiphish/.local/share/nvim/site-packages/vim-ultest/rplugin/python3/ultest/handler/runner/__init__.py",
line 168, in _run_group
cmd = self._vim.sync_call("ultest#adapter#build_cmd", tree[0], scope)
File "/home/hiphish/.local/share/nvim/site-packages/vim-ultest/rplugin/python3/ultest/vim_client/__init__.py", line
121, in sync_call
return self._eval(expr, sync=True)
File "/home/hiphish/.local/share/nvim/site-packages/vim-ultest/rplugin/python3/ultest/vim_client/__init__.py", line
134, in _eval
return self._vim.eval(expr, async_=not sync)
File "/home/hiphish/.local/lib/python3.9/site-packages/pynvim/api/nvim.py", line 295, in eval
return self.request('nvim_eval', string, **kwargs)
File "/home/hiphish/.local/lib/python3.9/site-packages/pynvim/api/nvim.py", line 182, in request
res = self._session.request(name, *args, **kwargs)
File "/home/hiphish/.local/lib/python3.9/site-packages/pynvim/msgpack_rpc/session.py", line 102, in request
raise self.error_wrapper(err)
pynvim.api.common.NvimError: Vim(let):E118: Too many arguments for function: test#base#build_args
To Reproduce
Create a file test_test.py with the following contents:
def test_numeric_inequality():
a = 2
b = 3
assert a != b
def test_numeric_equality():
a = 3
b = 3
assert a == bPlace the cursor on either test function and execute :Ultest or :UltestNearest.
Additional context
- Neovim version v0.5.0-dev+1360-ga7205e2b7 (nightly)
- pynvim version 0.4.3 (from pip)
- Python version 3.9
- OS: Void Linux
- Log file: vim-ultest.log
"E118: Too many arguments for function: clearmatches" in Neovim stable
Describe the bug
This happens in Neovim 0.4.4
The command :UltestSummaryOpen raises this error:
Error detected while processing function ultest#summary#open[2]..<SNR>165_OpenNewWindow[29]..<SNR>165_FullRender[2]..<SNR>165_Clear:
line 2:
E118: Too many arguments for function: clearmatches
After this the :Ultest command raises errors. the summary window doesn't update and the tests isn't marked; the whole plugin doesn't work with the summary window opened.
Attach this log with a :UltestSummaryOpen followed by a :Ultest in a file with two tests:
22:53:45 | INFO | MainThread | logging.py:create_logger:71 | Logger created
22:53:45 | DEBUG | MainThread | __init__.py:__init__:40 | Handler created
22:53:46 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:42 | Starting job with group update_positions
22:53:46 | INFO | Thread-1 | __init__.py:runner:164 | Updating positions in /home/terseus/programacion/python/gitignorehub/tests/test_dict_view.py
22:53:46 | DEBUG | Thread-1 | finder.py:find_all:16 | Converted pattern {'test': ['\\v^\\s*%(async )?def (test_\\w+)'], 'namespace': ['\\v^\\s*class (\\w+)']} to ['^\\s*(?:async )?def (test_\\w+)']
22:53:46 | DEBUG | Thread-1 | __init__.py:runner:189 | New test test_is_mapping-6355241463067513474 found in /home/terseus/programacion/python/gitignorehub/tests/test_dict_view.py
22:53:46 | DEBUG | Thread-1 | __init__.py:runner:189 | New test test_is_read_only4853966193254504374 found in /home/terseus/programacion/python/gitignorehub/tests/test_dict_view.py
22:53:46 | DEBUG | Thread-1 | __init__.py:runner:199 | No tests removed
22:53:46 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:57 | Finished job with group update_positions
22:54:00 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:42 | Starting job with group run_all
22:54:00 | INFO | Thread-1 | __init__.py:run:99 | Running all tests in /home/terseus/programacion/python/gitignorehub/tests/test_dict_view.py
22:54:00 | DEBUG | Thread-1 | processes.py:run_tests:156 | Sending test_is_mapping-6355241463067513474 to vim-test
22:54:00 | DEBUG | Thread-1 | processes.py:run_tests:156 | Sending test_is_read_only4853966193254504374 to vim-test
22:54:00 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:57 | Finished job with group run_all
22:54:00 | DEBUG | MainThread | __init__.py:strategy:60 | Received test from vim-test test_is_mapping-6355241463067513474 with args ['poetry', 'run', 'pytest', '/home/terseus/programacion/python/gitignorehub/tests/test_dict_view.py::test_is_mapping']
22:54:00 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:42 | Starting job with group test_is_mapping-6355241463067513474
22:54:00 | DEBUG | Thread-1 | processes.py:run:121 | Starting test process test_is_mapping-6355241463067513474 with command: ['poetry', 'run', 'pytest', '/home/terseus/programacion/python/gitignorehub/tests/test_dict_view.py::test_is_mapping']
22:54:00 | DEBUG | MainThread | __init__.py:strategy:60 | Received test from vim-test test_is_read_only4853966193254504374 with args ['poetry', 'run', 'pytest', '/home/terseus/programacion/python/gitignorehub/tests/test_dict_view.py::test_is_read_only']
22:54:00 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:42 | Starting job with group test_is_read_only4853966193254504374
22:54:00 | DEBUG | Thread-1 | processes.py:run:121 | Starting test process test_is_read_only4853966193254504374 with command: ['poetry', 'run', 'pytest', '/home/terseus/programacion/python/gitignorehub/tests/test_dict_view.py::test_is_read_only']
22:54:02 | DEBUG | Thread-1 | processes.py:run:140 | Test test_is_mapping-6355241463067513474 complete with exit code: 0
22:54:02 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:57 | Finished job with group test_is_mapping-6355241463067513474
22:54:02 | DEBUG | Thread-1 | processes.py:run:140 | Test test_is_read_only4853966193254504374 complete with exit code: 0
22:54:02 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:57 | Finished job with group test_is_read_only4853966193254504374
22:54:40 | INFO | MainThread | logging.py:create_logger:71 | Logger created
22:54:40 | DEBUG | MainThread | __init__.py:__init__:40 | Handler created
22:55:06 | INFO | MainThread | logging.py:create_logger:71 | Logger created
22:55:06 | DEBUG | MainThread | __init__.py:__init__:40 | Handler created
To Reproduce
- Install Neovim v0.4.4
- Install the plugin
- Open vim
- Execute
:UltestSummaryOpen
Expected behavior
Either make it compatible with Neovim v0.4.4, or include "Neovim nightly / v0.5" to the requirements in the README.
Additional context
- The PR with the change for
clearmatchesto add it a parameter: https://github.com/neovim/neovim/pull/12325/files#diff-2edf914db40ccdd12cdf8d7e236fe3f4d8323ad43aa300f92720afda81ebae1a - The function
clearmatchesin the eval table in Neovim v0.4.4: https://github.com/neovim/neovim/blob/release-0.4/src/nvim/eval.lua#L66 - With Neovim v0.5 the error doesn't happen.
- After removing the parameter from the
clearmatchesthe plugin works but I don't know what side effects this could have.
Jest failure output on TypeScript project is interpreted as potential binary file
Describe the bug
After running Ultest in a TypeScript test file, the popup terminal window interprets the output from Jest as a potential binary file and gives a warning (see screenshots) before showing the file. Entering the terminal window and typing y correctly shows the output, but as you can imagine it's not easy to do this every time (especially since I have to click on the popup terminal to interact with it).
I'm not sure whether this is an Ultest issue or a Jest issue, but the popup window seems to be adding some strange characters that aren't present when calling Jest directly from the command line.
My only configuration for Ultest / vim-test is adding --color=always to my Jest, and commenting it out doesn't make a difference, so it doesn't seem to be related.
Log:
01:18:42 | INFO | MainThread | logging.py:create_logger:71 | Logger created
01:18:42 | DEBUG | MainThread | __init__.py:__init__:40 | Handler created
01:18:42 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:42 | Starting job with group update_positions
01:18:42 | INFO | Thread-1 | __init__.py:runner:166 | Updating positions in src/test-function.test.ts
01:18:42 | DEBUG | Thread-1 | finder.py:find_all:16 | Converted pattern {'test': ['\\v^\\s*%(it|test)\\s*[( ]\\s*%("|\'|`)(.*)%("|\'|`)'], 'namespace': ['\\v^\\s*%(describe|suite|context)\\s*[( ]\\s*%("|\'|`)(.*)%("|\'|`)']} to ['^\\s*(?:it|test)\\s*[( ]\\s*(?:"|\'|`)(.*)(?:"|\'|`)']
01:18:42 | DEBUG | Thread-1 | __init__.py:runner:191 | New test should_fail_and_show_a_popup_window8269796582372893254 found in src/test-function.test.ts
01:18:42 | DEBUG | Thread-1 | __init__.py:runner:201 | No tests removed
01:18:42 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:57 | Finished job with group update_positions
01:18:45 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:42 | Starting job with group run_all
01:18:45 | INFO | Thread-1 | __init__.py:run:101 | Running all tests in src/test-function.test.ts
01:18:45 | DEBUG | Thread-1 | processes.py:run_tests:156 | Sending should_fail_and_show_a_popup_window8269796582372893254 to vim-test
01:18:45 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:57 | Finished job with group run_all
01:18:45 | DEBUG | MainThread | __init__.py:strategy:60 | Received test from vim-test should_fail_and_show_a_popup_window8269796582372893254 with args ['node_modules/.bin/jest', '--color=always', '--no-coverage', "-t 'should fail and show a popup window$'", '--', 'src/test-function.test.ts']
01:18:45 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:42 | Starting job with group should_fail_and_show_a_popup_window8269796582372893254
01:18:45 | DEBUG | Thread-1 | processes.py:run:121 | Starting test process should_fail_and_show_a_popup_window8269796582372893254 with command: ['node_modules/.bin/jest', '--color=always', '--no-coverage', '-t', 'should fail and show a popup window$', '--', 'src/test-function.test.ts']
01:18:46 | DEBUG | Thread-1 | processes.py:run:140 | Test should_fail_and_show_a_popup_window8269796582372893254 complete with exit code: 1
01:18:46 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:57 | Finished job with group should_fail_and_show_a_popup_window8269796582372893254
01:18:46 | DEBUG | MainThread | __init__.py:_present_output:87 | Showing should_fail_and_show_a_popup_window8269796582372893254 output
To Reproduce
Since it takes a little time to set up a new TypeScript + Jest project, I generated a default TypeScript config file and followed the instructions on Jest's Getting Started page to set up a minimal repo, which I've uploaded here.
Running npm install after cloning and then running :Ultest in test-function.test.ts should reproduce the error (unless the issue is completely on my end).
You can also compare the popup window's output to what Jest outputs from the command line by running npm run test.
Expected behavior
The terminal window should show Jest output without additional confirmation.
Screenshots
Additional context
Thanks for the great plugin! Let me know if you need any more information.
Runner stuck with CreateReactApp
Describe the bug
The testrunner gets stuck when running the tests
Please include language and test runner being used.
typescript with the default create-react-app template.
The test will be run with react-scripts test
Logs should be created using ULTEST_LOG_LEVEL=DEBUG ULTEST_LOG_FILE=vim-ultest.log nvim <test-file> and added here as well
20:07:35 | INFO | MainThread | logging.py:create_logger:101 | Logger created
20:07:36 | DEBUG | MainThread | init.py:init:43 | Handler created
20:07:36 | DEBUG | Thread-1 | init.py:_handle_coroutine:58 | Starting job with group update_positions
20:07:36 | INFO | Thread-1 | tracker.py:_async_update:55 | Updating positions in src/App.test.tsx
20:07:36 | DEBUG | Thread-1 | file.py:parse_file_structure:25 | Converted pattern {'test': ['\v^\s*%(it|test)\s*[( ]\s*%("|'|)(.*)%("|\'|)'], 'namespace': ['\v^\s*%(describe|suite|context)\s*[( ]\s*%("|'|)(.*)%("|\'|)']} to {'test': [re.compile('^\s*(?:it|test)\s*[( ]\s*(?:"|'|)(.*)(?:"|\'|)')], 'namespace': [re.compile('^\s*(?:describe|suite|context)\s*[( ]\s*(?:"|'|)(.*)(?:"|\'|)')]}
20:07:36 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test src/App.test.tsx found in src/App.test.tsx
20:07:36 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test renders_learn_react_link4787548909642993506 found in src/App.test.tsx
20:07:36 | DEBUG | Thread-1 | tracker.py:_remove_old_positions:125 | No tests removed
20:07:36 | DEBUG | Thread-1 | init.py:_handle_coroutine:78 | Finished job with group update_positions
20:07:49 | INFO | MainThread | init.py:run_nearest:125 | Running nearest test in src/App.test.tsx at line 1
20:07:49 | DEBUG | MainThread | init.py:_register_started:281 | Registering renders_learn_react_link4787548909642993506 as started
20:07:49 | DEBUG | Thread-1 | init.py:_handle_coroutine:58 | Starting job with group renders_learn_react_link4787548909642993506
20:07:49 | DEBUG | Thread-1 | processes.py:run:50 | Starting test process renders_learn_react_link4787548909642993506 with command ['node_modules/.bin/react-scripts', 'test', '-t', 'renders learn react link$', 'src/App.test.tsx'], cwd = None, env = None
20:12:02 | INFO | MainThread | logging.py:create_logger:101 | Logger created
20:12:02 | DEBUG | MainThread | init.py:init:43 | Handler created
20:12:02 | DEBUG | Thread-1 | init.py:_handle_coroutine:58 | Starting job with group update_positions
20:12:02 | INFO | Thread-1 | tracker.py:_async_update:55 | Updating positions in src/App.test.tsx
20:12:02 | DEBUG | Thread-1 | file.py:parse_file_structure:25 | Converted pattern {'test': ['\v^\s*%(it|test)\s*[( ]\s*%("|'|)(.*)%("|\'|)'], 'namespace': ['\v^\s*%(describe|suite|context)\s*[( ]\s*%("|'|)(.*)%("|\'|)']} to {'test': [re.compile('^\s*(?:it|test)\s*[( ]\s*(?:"|'|)(.*)(?:"|\'|)')], 'namespace': [re.compile('^\s*(?:describe|suite|context)\s*[( ]\s*(?:"|'|)(.*)(?:"|\'|)')]}
20:12:02 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test src/App.test.tsx found in src/App.test.tsx
20:12:02 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test renders_learn_react_link1151337496413743625 found in src/App.test.tsx
20:12:02 | DEBUG | Thread-1 | tracker.py:_remove_old_positions:125 | No tests removed
20:12:02 | DEBUG | Thread-1 | init.py:_handle_coroutine:78 | Finished job with group update_positions
20:12:12 | INFO | MainThread | init.py:run_nearest:125 | Running nearest test in src/App.test.tsx at line 1
20:12:12 | DEBUG | MainThread | init.py:_register_started:281 | Registering renders_learn_react_link1151337496413743625 as started
20:12:12 | DEBUG | Thread-1 | init.py:_handle_coroutine:58 | Starting job with group renders_learn_react_link1151337496413743625
20:12:12 | DEBUG | Thread-1 | processes.py:run:50 | Starting test process renders_learn_react_link1151337496413743625 with command ['node_modules/.bin/react-scripts', 'test', '-t', 'renders learn react link$', 'src/App.test.tsx'], cwd = None, env = None
To Reproduce
Steps to reproduce the behavior:
npx create-react-app reproduction-example --template typescript
cd reproduction-example
npm install
nvim src/App.test.tsx
:UltestNearest
Expected behavior
Running the test
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
If I run the command from the log output my self it runs in an interactive way, I think this might be the issue
node_modules/.bin/react-scripts test -t 'renders learn react link' src/App.test.tsx
If you set the env variable CI=true it is no longer interactive and just prints the result:
Bug: Plugin needs `pynvim` installed in activated venv
Describe the bug
I tried to make it run and it does work now - however I had to install pynvim in the venv I am using for my projects - it is installed in my main environment but for some reason ultest does only consider my venv-interpreter. As I work with poetry, this would imply I needed to install the module in each project, which is a minor annoyance but I would like to know whether it's not possible to separate some of the calls that reference the editor functionality. I see in
pynvim there, I assume that happens with the $VIRTUAL_ENV interpreter, which is called if you do these calls here:vim-ultest/autoload/ultest/handler.vim
Line 35 in b2b9caf
This is not a "bug" per se but I'd say it's a desirable behaviour! :)
To Reproduce
Steps to reproduce the behavior:
- Install
vim-ultestwithpacker - install
pynvimin system interpreter - create new venv, install
pytestand activate it - configure pytest as test launcher in config file
- launch nvim on file containing tests
Expected behavior
vim-ultest works if the currently activated venv is not using pynvim and sources the interpreter defined in g:python3_host_prog instead to prevent the (small) issue of installing pynvim into all projects.
Debugging recipe in wiki needs minor correction
At https://github.com/rcarriga/vim-ultest/wiki/Debugging-Recipes, the pytest recipe refers to a module_index variable that's not defined. I don't (yet) fully understand what ought to be in cmd, but I used the following code just to follow the intent of the code in the recipe, and I can confirm it works (i.e., :UltestDebug starts up a debugging session).
+ local module_index = 1
+ if vim.tbl_contains(non_modules, cmd[1]) then
+ module_index = 3
+ end
+ local module = cmd[module_index]
+ local args = vim.list_slice(cmd, module_index + 1)
(I didn't see a way to edit the wiki directly, and I'm not sure how to make a PR against it, hence this issue.)
Errors after install plugin.
Thanks for this great plugin! But after installation I get this error:
Do you need any logs for debugging?
Question about the relationship to vim-test
Describe the bug
For a go test file, the commands don't seem to work properly.
Let's say I open a ..._test.go file, when I run :TestFile, it runs all the tests, and when I do :TestNearest, it correctly run the test I'm in using the following command (I'm using richgo for my go tests):
richgo test -run '\''MyTest$'\'' ./parent/child/current'; richgo test -run 'MyTest$' ./parent/child/current
However, when I do :UltestNearest, I see no Go files in /parent
I open vim in ./parent directory and I go to the file ./parent/child/current/file_test.go, and that's where I'm trying to run the tests
Also, I'm not sure if I see this error because of what's happening above, but I thought I mention this too.
When I run :UltestSummary, I see the following error:
Error detected while processing function ultest#summary#toggle[4]..ultest#summary#open[2]..<SNR>484_OpenNewWindow[29]..<SNR>484_FullRender[2]..<SNR>484_Clear:
line 2:
E118: Too many arguments for function: clearmatches
To Reproduce
I think the explanation covers this part
Expected behavior
I was expecting for vim-ultest to mimic what vim-test does, with added features
Screenshots
Here's a screenshot of the output. Maybe it's worth noting that the right border of the box seems to be missing inside tmux. when I run it outside of tmux, the box seems to be fine ....... actually, I lied! I exited and tried again and it was find inside of tmux, but I'm keeping the screenshot just in case 🙂
Sorry if I'm bothering you with all the issues I'm creating, but the plugin seems to be very promising and useful I'm doing my best to use it, but I'm not able to succeed
Getting error when opening a test file
Describe the bug
I'm opening a test file (a go file in my case), and I'm getting the following error:
python3-rplugin-host: Async request caused an error:
Vim(let):E117: Unknown function: list2str
To Reproduce
Open a ..._test.go file
Expected behavior
I shouldn't see any errors
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
I have pynvim package installed, and I'm not sure what's missing
The message doesn't seem to be directly coming from the plugin, but since this plugin lists pynvim as requirements, and when I disable this plugin, I can open the test file, I'm guessing the error is coming from this plugin
Make it clear that popup delay depends on `updatetime` option
Describe the bug
I'm not entirely sure this is related to vim-ultest rather than nvim itself, but when I first installed the plugin, the popup window with the failed test information took exactly 4 seconds to display (the one that pops up on hover on the first line of the failed test).
I checked with :options and found out that I had updatetime set to 4000 (which, I guess, is the default value). Reducing it to 100 actually makes the popup window appear instantly.
However, this will cause a lot more writes (40 times more) to the swap file, if it's used, therefor raising a potential issue on SSD devices. I would add this information to the readme, either telling users to disable swap files or to know the tradeoffs of a low updatetime.
Thanks for this plugin and keep up the great work!
Getting error randomly when the current buffer is a .vim file
Describe the bug
I'm using vim-ctrlspace and I have an open buffer of a .vim file. When I want to list the tabs using vim-ctrlspace, I see the following error:
error caught in async handler '/home/farzad/.vim/plugged/vim-ultest/rplugin/python3/ultest:function:_ultest_update_positions [['init.vim']]'
Traceback (most recent call last):
File "/home/farzad/.vim/plugged/vim-ultest/rplugin/python3/ultest/__init__.py", line 98, in _update_positions
self.handler.update_positions(*args)
File "/home/farzad/.vim/plugged/vim-ultest/rplugin/python3/ultest/handler/__init__.py", line 152, in update_positions
vim_patterns = self._vim.sync_call("ultest#adapter#get_patterns", file_name)
File "/home/farzad/.vim/plugged/vim-ultest/rplugin/python3/ultest/vim_client/__init__.py", line 128, in sync_call
return self._eval(expr, sync=True)
File "/home/farzad/.vim/plugged/vim-ultest/rplugin/python3/ultest/vim_client/__init__.py", line 141, in _eval
return self._vim.eval(expr, async_=not sync)
File "/usr/lib/python3.9/site-packages/pynvim/api/nvim.py", line 295, in eval
return self.request('nvim_eval', string, **kwargs)
File "/usr/lib/python3.9/site-packages/pynvim/api/nvim.py", line 182, in request
res = self._session.request(name, *args, **kwargs)
File "/usr/lib/python3.9/site-packages/pynvim/msgpack_rpc/session.py", line 102, in request
raise self.error_wrapper(err)
pynvim.api.common.NvimError: Vim(return):E484: Can't open file init.vim
This is the log file:
22:53:12 | INFO | MainThread | logging.py:create_logger:71 | Logger created
22:53:12 | DEBUG | MainThread | __init__.py:__init__:40 | Handler created
22:53:14 | DEBUG | MainThread | __init__.py:update_positions:154 | No patterns found for init.vim
To Reproduce
- Open a
.vimfile - Press ctrl + space to display
vim-ctrlspacemenu - Press l to list tabs in
vim-ctrlspace - See the error
Expected behavior
There shouldn't be any errors!
Go: Configuration for using delve DAP rather than vscode-go
Not sure if this is a bug or a user error but I'm leaning towards the latter :) In the docs there is a sample configuration for vscode-go which parses the output to see if a test failed or not because there is no error code returned. With delve an error code is returned so this is not an issue.
Using the following configuration
dap = {
type = "go",
name = "Debug test",
request = "launch",
mode = "test", -- Mode is important
program = "${workspaceFolder}",
-- program = "${file}"
dlvToolPath = vim.fn.exepath("dlv"),
args = args
},
:DebugNearest and :debug does successfully stop at breakpoints. The issue is that the sign stays at 'running' as it appears the error code is not checked. I'm not sure if I am missing a particular configuration above, I thought code checking would have been the default.
Anyways this is super low priority, running :Ultest afterwards will refresh the signs.
[Feature Request] Provide :UltestAttachDebug command
New issue to replace #49 to keep things a bit cleaner
The functionality to attach to current processes and open a debugger in a floating window works well using :UltestAttach. What would be interesting is if similar functionality could be added to attach to programs running using DAP.
For example, with debugpy we could add
import debugpy
debugpy.listen(5678)
debugpy.beakpoint()
Then running :UltestAttachDebug would attach to this instance and open the tray/sidebar.
Would something like this be feasible?
Jest test freeze, but works with vim-test
Typescript, jest
Running a test freeze
Running it directly with vim-test works properly.
Log:
...
20:45:01 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:78 | Finished job with group update_positions
20:45:07 | INFO | MainThread | __init__.py:run_nearest:125 | Running nearest test in src/pipes/tests/PipeForm.test.tsx at line 55
20:45:07 | DEBUG | MainThread | __init__.py:_register_started:281 | Registering should_render_form,_header_and_submit_button-4681889750434716771 as started
20:45:07 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:58 | Starting job with group should_render_form,_header_and_submit_button-4681889750434716771
20:45:07 | DEBUG | Thread-1 | processes.py:run:50 | Starting test process should_render_form,_header_and_submit_button-4681889750434716771 with command ['node_modules/.bin/react-scripts', 'test', '-t', '^<PipeForm> should render form, header and submit button$', 'src/pipes/tests/PipeForm.test.tsx'], cwd = None, env = None
20:45:08 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:45:08 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:45:08 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:45:08 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:45:08 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:45:08 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
...
Log indicates running: ['node_modules/.bin/react-scripts', 'test', '-t', '^ should render form, header and submit button$', 'src/pipes/tests/PipeForm.test.tsx'], cwd = None, env = None
Running this command manually works properly: node_modules/.bin/react-scripts test -t '^<PipeForm> should render form, header and submit button$' src/pipes/tests/PipeForm.test.tsx
Nvim-dap, Pytest, Debugpy and Docker
Firstly, this isn't an issue with the plugin at all, more of a general question on being able to use vim-ultest to debug remotely into a Docker container.
With my current config (for reference rather than to understand), I use a pretty hefty command to pass to the command line which triggers Docker to wait for any feedback from nvim-dap:
docker-compose -f "./docker-compose.yml" exec -T -w /usr/src/app debug python -m debugpy --listen ' ..
debug_host .. ':' .. debug_port .. ' --wait-for-client -m pytest ' .. test_method[1]
Where test_method is the test name for the nearest test (something I pinched from vim-test). Using the instructions in the vim-ultest docs, combined with my previous setup, I form the following:
require("ultest").setup({
builders = {
['python#pytest'] = function(cmd)
local debug_host = '0.0.0.0'
local debug_port = 5678
local test_method = fn['test#python#pytest#build_position']('nearest', {
file = fn['expand']('%'),
line = fn['line']('.'),
col = fn['col']('.')
})
local args = 'docker-compose -f "./docker-compose.yml" exec -T -w /usr/src/app debug python -m debugpy --listen ' .. debug_host .. ':' .. debug_port .. ' --wait-for-client -m pytest ' .. test_method[1]
return {
dap = {
type = "python",
request = "attach",
connect = {
host = debug_host,
port = debug_port
},
args = args,
mode = "remote",
name = "Remote Attached Debugger",
cwd = fn.getcwd(),
pathMappings = {{
localRoot = fn.getcwd(), -- Wherever your Python code lives locally.
remoteRoot = "/usr/src/app" -- Wherever your Python code lives in the container.
}}
}
}
end
}
})When I run this with UltestDebugNearest I get Invalid adapter: nil which is an nvim-dap error. Which seems odd as I use it with nvim-dap in my previous setup.
Is there anything obvious I may be overlooking? Granted I need to actually make use of the vim-ultest cmd function to pass to nvim-dap.
Request for Ultest equivalent to vim-test's :TestSuite
Thanks for writing this plugin! Similar to #69 I'm wondering about the possibility of adding support for running an entire test suite like vim-test's :TestSuite.
If this would be a reasonable first issue, I'd be happy to try and add support and raise a PR if you don't mind giving me an idea of where to start.
[Feature Request] Attach to process associated with file
Looking at the code I see
command! UltestAttach call ultest#output#attach(ultest#handler#get_nearest_test(line("."), expand("%:."), v:false))
This gives me the impression that if no nearest test is found then no process will be attached to. What would be nice if given the following file
#! usr/bin/env python
import pdb
if __name__ == "__main__":
pdb.set_trace()
print("hello")
If we ran the :UltestAttach command, it would first check for nearest test and try to attach. If no test is found as a fallback it will try to find the (newest?) process which contains the file name and tries to attach to that.
Would something like this be feasible?
Unicode icons are not portable
Several of the default icons used are in the private use area of Unicode, which means they can vary wildly from font to font and will most likely look like gibberish to anyone who is not using the exact same font as you. I propose replacing the defaults with something standardized; it will not look the same to everyone, but at least it will look like more or less similar.
The signs in question are:
g:ultest_pass_signg:ultest_fail_signg:ultest_running_signg:ultest_not_run_sign
I propose:
g:ultest_pass_sign:✓Check Mark U+2713g:ultest_fail_sign:🗲Lightning Mood U+1F5F2g:ultest_running_sign:🗘Clockwise Right and Left Semicircle Arrows U+1F5D8g:ultest_not_run_sign:?Question Mark U+003F
Error on new installation
Describe the bug
After install latest version starting vim gets me the following error message. The error comes back every few seconds. A normal usage of vim is impossible with that.
Error detected while processing function ultest#handler#get_nearest_test:
line 2:
E117: Unknown function: _ultest_get_nearest_test
Error detected while processing function ultest#handler#get_nearest_test:
line 2:
E15: Invalid expression: _ultest_get_nearest_test(a:line, a:file_name, a:strict)
To Reproduce
Steps to reproduce the behavior:
Install latest version of your plugin. Start vim. Wait.
Expected behavior
Produce no error message on vim start.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
Virtual Text Highlighting on the line(s) of the failure/error
Hi,
It would be nice if we could highlight the line that the error occurs, rather than just on the line of the function, maybe with some virtual text similar to LSP diagnostics. I've taken a few screenshots to try and demonstrate. Ideally it could highlight across buffers use a "stack trace" or something so you could "go to definition" on a function and open another buffer and it would continue to show the relevant line. I'm currently using the phpunitkit plugin for sublime text which could serve as a reference
current: only highlights the line of the function that failed
sublime text: highlights the line where the failure/error occurs
lsp: as an example of what it could look like
I'm willing to try and help but my experience in python/lua is very limited.
Thanks!
Is there any alternative for `:TestLast`?
The title speaks of itself. Thank you for the plugin.
Ultest does not detect custom vim-test runners
Describe the bug
While vim-test comes with a sane list of runners per default, it is far from complete. But that is not of an issue as it is pretty simple to just add new runners to the plugin. I have such runners in my setup. Here for example I add jest for the filetype typescript. This runner is very simple as it basically just brings the already existing jest runner for javascript into the typescript filetype plus tiny additions. This was/is working perfectly fine with vim-test.
So if I open a related test file for this and run for example :TestFile this works. If I now run :Ultest nothing happens. If I open the summary window with :UltestSummary the list of detected tests is empty.!
Logs should be created using ULTEST_LOG_LEVEL=DEBUG ULTEST_LOG_FILE=vim-ultest.log nvim <test-file> and added here as well
10:44:13 | INFO | MainThread | logging.py:create_logger:71 | Logger created
10:44:13 | DEBUG | MainThread | __init__.py:__init__:40 | Handler created
10:44:13 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:42 | Starting job with group run_all
10:44:13 | INFO | Thread-1 | __init__.py:run:101 | Running all tests in tests/unit/router/guards/global.spec.ts
10:44:13 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:57 | Finished job with group run_all
10:44:21 | DEBUG | MainThread | __init__.py:update_positions:160 | No patterns found for tests/unit/router/guards/global.spec.ts
To Reproduce
Create a custom runner and put into your path somewhere under autoload/test/<filetype>/<runner>.vim. As an example you can take the example I liked above. Add the runner to your custom runners with let g:test#custom_runners = { '<filetype>': ['<runner>'] }. Depending on your exact setup you might need to enable the runner in test#enabled_runners. Now open a test file for this <filetype> which uses this <runner>. Try to run a vim-test command to run a test case and see it succeed. Now try the same with vim-ultest. It does not work.
Expected behavior
vim-ultest can pickup all custom runners for vim-test.
Go: a failing test appears to put nvim into insert mode at the end
Describe the bug
Running Ultest-nearest on a passing test works as expected. Running Ultest-nearest on a failing test puts neovim into insert mode at the end. Running Ultest-file which contains a failing test also puts neovim into insert mode.
11:27:09 | INFO | MainThread | logging.py:create_logger:98 | Logger created
11:27:09 | DEBUG | MainThread | __init__.py:__init__:43 | Handler created
11:27:09 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:58 | Starting job with group update_positions
11:27:09 | INFO | Thread-1 | tracker.py:_async_update:55 | Updating positions in dap_test.go
11:27:09 | DEBUG | Thread-1 | file.py:parse_file_structure:25 | Converted pattern {'test': ['\\v^\\s*func (\\w+)'], 'namespace': []} to {'test': [re.compile('^\\s*func (\\w+)')], 'namespace': []}
11:27:09 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test dap_test.go found in dap_test.go
11:27:09 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test TestSuccess-3646284460309850492 found in dap_test.go
11:27:09 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test TestFailure-3646284460309850492 found in dap_test.go
11:27:09 | DEBUG | Thread-1 | tracker.py:_remove_old_positions:125 | No tests removed
11:27:09 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:78 | Finished job with group update_positions
11:27:21 | INFO | MainThread | __init__.py:run_nearest:125 | Running nearest test in dap_test.go at line 9
11:27:21 | DEBUG | MainThread | __init__.py:_register_started:281 | Registering TestSuccess-3646284460309850492 as started
11:27:21 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:58 | Starting job with group TestSuccess-3646284460309850492
11:27:21 | DEBUG | Thread-1 | processes.py:run:50 | Starting test process TestSuccess-3646284460309850492 with command ['go', 'test', '-run', 'TestSuccess$', './.'], cwd = None, env = None
11:27:21 | DEBUG | Thread-1 | processes.py:run:76 | Process TestSuccess-3646284460309850492 complete with exit code: 0
11:27:21 | DEBUG | Thread-1 | __init__.py:_register_result:292 | Registering TestSuccess-3646284460309850492 as exited with result {"id": "TestSuccess-3646284460309850492", "file": "dap_test.go", "code": 0, "output": "/var/folders/x4/wv98pc6d38n0ykn769h63jjw0000gn/T/ultestznheystd/dap_test_go/TestSuccess-3646284460309850492_out"}
11:27:21 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:78 | Finished job with group TestSuccess-3646284460309850492
11:27:25 | INFO | MainThread | __init__.py:run_nearest:125 | Running nearest test in dap_test.go at line 14
11:27:25 | DEBUG | MainThread | __init__.py:_register_started:281 | Registering TestFailure-3646284460309850492 as started
11:27:25 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:58 | Starting job with group TestFailure-3646284460309850492
11:27:25 | DEBUG | Thread-1 | processes.py:run:50 | Starting test process TestFailure-3646284460309850492 with command ['go', 'test', '-run', 'TestFailure$', './.'], cwd = None, env = None
11:27:26 | DEBUG | Thread-1 | processes.py:run:76 | Process TestFailure-3646284460309850492 complete with exit code: 1
11:27:26 | DEBUG | Thread-1 | __init__.py:_register_result:292 | Registering TestFailure-3646284460309850492 as exited with result {"id": "TestFailure-3646284460309850492", "file": "dap_test.go", "code": 1, "output": "/var/folders/x4/wv98pc6d38n0ykn769h63jjw0000gn/T/ultestznheystd/dap_test_go/TestFailure-3646284460309850492_out"}
11:27:26 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:78 | Finished job with group TestFailure-3646284460309850492
11:27:26 | DEBUG | MainThread | __init__.py:_present_output:109 | Showing TestFailure-3646284460309850492 output
11:27:31 | INFO | MainThread | __init__.py:run_nearest:125 | Running nearest test in dap_test.go at line 0
11:27:31 | DEBUG | MainThread | __init__.py:_register_started:281 | Registering dap_test.go as started
11:27:31 | DEBUG | MainThread | __init__.py:_register_started:281 | Registering TestSuccess-3646284460309850492 as started
11:27:31 | DEBUG | MainThread | __init__.py:_register_started:281 | Registering TestFailure-3646284460309850492 as started
11:27:31 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:58 | Starting job with group dap_test.go
11:27:31 | DEBUG | Thread-1 | processes.py:run:50 | Starting test process dap_test.go with command ['go', 'test'], cwd = None, env = None
11:27:31 | DEBUG | Thread-1 | processes.py:run:76 | Process dap_test.go complete with exit code: 1
11:27:31 | DEBUG | Thread-1 | __init__.py:_register_result:292 | Registering dap_test.go as exited with result {"id": "dap_test.go", "file": "dap_test.go", "code": 1, "output": "/var/folders/x4/wv98pc6d38n0ykn769h63jjw0000gn/T/ultestznheystd/dap_test_go/dap_test_go_out"}
11:27:31 | DEBUG | Thread-1 | __init__.py:_register_result:292 | Registering TestSuccess-3646284460309850492 as exited with result {"id": "TestSuccess-3646284460309850492", "file": "dap_test.go", "code": 1, "output": "/var/folders/x4/wv98pc6d38n0ykn769h63jjw0000gn/T/ultestznheystd/dap_test_go/dap_test_go_out"}
11:27:31 | DEBUG | Thread-1 | __init__.py:_register_result:292 | Registering TestFailure-3646284460309850492 as exited with result {"id": "TestFailure-3646284460309850492", "file": "dap_test.go", "code": 1, "output": "/var/folders/x4/wv98pc6d38n0ykn769h63jjw0000gn/T/ultestznheystd/dap_test_go/dap_test_go_out"}
11:27:31 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:78 | Finished job with group dap_test.go
11:27:31 | DEBUG | MainThread | __init__.py:_present_output:109 | Showing dap_test.go output
11:27:31 | DEBUG | MainThread | __init__.py:_present_output:109 | Showing TestSuccess-3646284460309850492 output
11:27:31 | DEBUG | MainThread | __init__.py:_present_output:109 | Showing TestFailure-3646284460309850492 output
Nothing happens on Ultest* commands
Very similar to #21.
Describe the bug
Nothing happens when running Ultest* commands. Tests are seemingly detected fine (they show up in UltestSummary tree), however, they are not actually running. I am in Typescript test file, using Jest. :TestFile from vim-test runs succesfully.
Logs should be created using ULTEST_LOG_LEVEL=DEBUG ULTEST_LOG_FILE=vim-ultest.log nvim <test-file> and added here as well:
21:33:00 | INFO | MainThread | logging.py:create_logger:98 | Logger created
21:33:00 | DEBUG | MainThread | init.py:init:41 | Handler created
21:33:01 | DEBUG | Thread-1 | init.py:_handle_coroutine:57 | Starting job with group update_positions
21:33:01 | INFO | Thread-1 | tracker.py:_async_update:52 | Updating positions in /path/to/bar.test.ts
21:33:01 | DEBUG | Thread-1 | file.py:parse_file_structure:22 | Converted pattern {'test': ['\v^\s*%(it|test)\s*[( ]\s*%("|'|)(.*)%("|\'|)'], 'namespace': ['\v^\s*%(describe|suite|context)\s*[( ]\s*%("|'|)(.*)%("|\'|)']} to {'test': [re.compile('^\s*(?:it|test)\s*[( ]\s*(?:"|'|)(.*)(?:"|\'|)')], 'namespace': [re.compile('^\s*(?:describe|suite|context)\s*[( ]\s*(?:"|'|)(.*)(?:"|\'|)')]}
21:33:01 | DEBUG | Thread-1 | tracker.py:_async_update:79 | New test /path/to/bar.test.ts found in /path/to/bar.test.ts
21:33:01 | DEBUG | Thread-1 | tracker.py:_async_update:79 | New test bar5117784500479910972 found in /path/to/bar.test.ts
21:33:01 | DEBUG | Thread-1 | tracker.py:_async_update:79 | New test foo0 found in /path/to/bar.test.ts
21:33:01 | DEBUG | Thread-1 | tracker.py:_async_update:79 | New test foo1 found in /path/to/bar.test.ts
21:33:01 | DEBUG | Thread-1 | tracker.py:_async_update:79 | New test foo2 found in /path/to/bar.test.ts
21:33:01 | DEBUG | Thread-1 | tracker.py:_async_update:79 | New test foo3 found in /path/to/bar.test.ts
21:33:01 | DEBUG | Thread-1 | tracker.py:_async_update:79 | New test foo4 found in /path/to/bar.test.ts
21:33:01 | DEBUG | Thread-1 | tracker.py:_async_update:79 | New test foo5 found in /path/to/bar.test.ts
21:33:01 | DEBUG | Thread-1 | tracker.py:_async_update:79 | New test foo6 found in /path/to/bar.test.ts
21:33:01 | DEBUG | Thread-1 | tracker.py:_async_update:79 | New test foo7 found in /path/to/bar.test.ts
21:33:01 | DEBUG | Thread-1 | tracker.py:_async_update:79 | New test foo8 found in /path/to/bar.test.ts
21:33:01 | DEBUG | Thread-1 | tracker.py:_remove_old_positions:122 | No tests removed
21:33:01 | DEBUG | Thread-1 | init.py:_handle_coroutine:77 | Finished job with group update_positions
21:33:17 | INFO | MainThread | init.py:run_nearest:125 | Running nearest test in bar.test.ts at line 0
21:33:17 | INFO | MainThread | init.py:run_nearest:129 | No tests found for bar.test.ts rerunning after processing positions
To Reproduce
See above
Expected behavior
Tests actually run
Screenshots
None
Additional context
:checkhealth does not show any problems, remote plugins are up-to-date, Python3 and pynvim are available (I am also using UltiSnips which need Python and are functioning fine).
E5108: Error executing lua ...es/neovim/.config/nvim/plugged/vim-ultest/lua/ultest.lua:60: attempt to index local 'test' (a userdata value)
Describe the bug
While trying to run a TypeScript (filetype typescript) test with UltestDebugNearest, I run into this:
E5108: Error executing lua ...es/neovim/.config/nvim/plugged/vim-ultest/lua/ultest.lua:60: attempt to index local 'test' (a userdata value)
The vim-ultest.log file contains this:
10:02:19 | INFO | MainThread | logging.py:create_logger:74 | Logger created
10:02:19 | DEBUG | MainThread | __init__.py:__init__:40 | Handler created
Additional context
nvim --version
NVIM v0.5.0-dev+1231-g48e805728
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/build/nvim/parts/nvim/build/build/config -I/build/nvim/parts/nvim/build/src -I/build/nvim/parts/nvim/build/.deps/usr/include -I/usr/include -I/build/nvim/parts/nvim/build/build/src/nvim/auto -I/build/nvim/parts/nvim/build/build/include
Compiled by root@lgw01-amd64-055
Features: +acl +iconv +tui
See ":help feature-compile"
system vimrc file: "$VIM/sysinit.vim"
fall-back for $VIM: "/usr/share/nvim"
Run :checkhealth for more info
python --version
Python 3.8.6
Jank caused due to result in floating window
Language: Dart/Flutter
I would prefer to have a way to increase the hold time before the plugin pops up the floating window with the test result. It causes jank when trying to move through the buffer. A "hoverDelay".
Undetected Tests
Language: dart/flutter
The tests aren't detected if the description of the text is on the next line (due to it being too long).
If I cut out a few words out of the description such that the description is on the sae line as the function call of test(), the tests are detected.
No feedback for Elixir test
Describe the bug
No output whatsoever when testing an Elixir ExUnit case.
To Reproduce
Steps to reproduce the behavior:
- Install elixir (I'm running 1.10.3)
- Clone https://github.com/aerosol/foo
ULTEST_LOG_LEVEL=DEBUG ULTEST_LOG_FILE=ultest.log nvim test/foo_test.exs- Run
:Ultest,:UltestSummaryOpen
Debug output:
(carb) /tmp/foo $ tail -f ultest.log
11:43:24 | INFO | MainThread | logging.py:create_logger:71 | Logger created
11:43:24 | DEBUG | MainThread | __init__.py:__init__:40 | Handler created
11:43:33 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:42 | Starting job with group run_all
11:43:33 | INFO | Thread-1 | __init__.py:runner:101 | Running all tests in test/foo_test.exs
11:43:33 | DEBUG | Thread-1 | jobs.py:_handle_coroutine:54 | Finished job with group run_all
Expected behavior
Any feedback in neovim instance.
Screenshots
Additional context
Add any other context about the problem here.
Error when opening buffer in directory with restricted access
Describe the bug
Prints out error message Error: vim-ultest encountered an unknown error on startup, check v:exception
Logs couldn't be created as I was in the /usr/local/share/nvim/runtime/syntax and there isn't permission to create a file in that directory. I also tried to name the file ~/vim-ultest.log to create it in the home directory, but that didn't work as well
To Reproduce
Go to /usr/local/share/nvim/runtime/syntax and open a buffer in neovim. It should prompt you with the error Error: vim-ultest encountered an unknown error on startup, check v:exception. It seems like I only get this message when opening a buffer in a directory with restricted access.
It also doesn't print the error message when running with sudo.
Expected behavior
Don't print any error message
Screenshots
Screen.Recording.2021-06-10.at.10.51.22.mov
Additional context
At first it printed out Error: vim-ultest remote function not detected, try running :UpdateRemotePlugins on install/update, but this seems to be fixed by 2032c74. However, I tried to do :UpdateRemotePlugins again after that commit, and then it came back. I tried to do it even more times, and then it suddenly disappeared again showing the error I am receiving now.
Nothing happens on any Ult* command
Describe the bug
When attempting to run any of the Ult* commands, nothing happens.
Output of vim-ultest.log after running UltestNearest and then UltestAttach:
12:22:23 | INFO | MainThread | logging.py:create_logger:71 | Logger created
12:22:23 | DEBUG | MainThread | __init__.py:__init__:40 | Handler created
12:22:30 | INFO | MainThread | __init__.py:run_nearest:115 | Running nearest test in spec/models/fast_forward_spec.rb at line 139
Running tests with TestNearest from vim-test work as expected.
To Reproduce
Call :UltestNearest, etc.
Expected behavior
Tests are executed.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
This is a Ruby on Rails project. Not sure if that matters.
Floating window for summary pane
It would be amazing if we could have support for showing summary pane as a floating window, since a lot of times, the test description strings are long. So floating window seems better for those kind of scenarios
Any plan to support windows?
This plugin works very well on linux, but does not work on windows, since the pty module does not work on windows according to python's official documentation(in fact, it does not work on windows at all since there's no termios module):
vim-ultest/rplugin/python3/ultest/handler/runner/handle.py
Lines 1 to 5 in dfea06d
The pty module defines operations for handling the pseudo-terminal concept: starting another process and being able to write to and read from its controlling terminal programmatically.
Because pseudo-terminal handling is highly platform dependent, there is code to do it only for Linux. (The Linux code is supposed to work on other platforms, but hasn’t been tested yet.)
Any plan to support windows?
Go: one failing tests makes all tests fail
Testing code
package main_test
import (
"fmt"
"testing"
)
func TestSuccess(t *testing.T) {
a := 1
fmt.Print(a)
}
func TestFailure(t *testing.T) {
t.Fatal("failed test")
}
Running :Ultest shows both tests as failing. This makes the next failing test mapping useless. Both test show the same error. Commenting out the t.Fatal makes both tests pass.
logs
19:51:45 | INFO | MainThread | logging.py:create_logger:98 | Logger created
19:51:45 | DEBUG | MainThread | __init__.py:__init__:43 | Handler created
19:51:45 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:58 | Starting job with group update_positions
19:51:45 | INFO | Thread-1 | tracker.py:_async_update:55 | Updating positions in dap_test.go
19:51:45 | DEBUG | Thread-1 | file.py:parse_file_structure:25 | Converted pattern {'test': ['\\v^\\s*func (\\w+)'], 'namespace': []} to {'test': [re.compile('^\\s*func (\\w+)')], 'namespace': []}
19:51:45 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test dap_test.go found in dap_test.go
19:51:45 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test TestSuccess-4403637724796131416 found in dap_test.go
19:51:45 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test TestFailure-4403637724796131416 found in dap_test.go
19:51:45 | DEBUG | Thread-1 | tracker.py:_remove_old_positions:125 | No tests removed
19:51:45 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:78 | Finished job with group update_positions
19:51:48 | INFO | MainThread | __init__.py:run_nearest:125 | Running nearest test in dap_test.go at line 0
19:51:48 | DEBUG | MainThread | __init__.py:_register_started:281 | Registering dap_test.go as started
19:51:48 | DEBUG | MainThread | __init__.py:_register_started:281 | Registering TestSuccess-4403637724796131416 as started
19:51:48 | DEBUG | MainThread | __init__.py:_register_started:281 | Registering TestFailure-4403637724796131416 as started
19:51:48 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:58 | Starting job with group dap_test.go
19:51:48 | DEBUG | Thread-1 | processes.py:run:50 | Starting test process dap_test.go with command ['go', 'test'], cwd = None, env = None
19:51:49 | DEBUG | Thread-1 | processes.py:run:76 | Process dap_test.go complete with exit code: 1
19:51:49 | DEBUG | Thread-1 | __init__.py:_register_result:292 | Registering dap_test.go as exited with result {"id": "dap_test.go", "file": "dap_test.go", "code": 1, "output": "/var/folders/x4/wv98pc6d38n0ykn769h63jjw0000gn/T/ultestg8sv6o5y/dap_test_go/dap_test_go_out"}
19:51:49 | DEBUG | Thread-1 | __init__.py:_register_result:292 | Registering TestSuccess-4403637724796131416 as exited with result {"id": "TestSuccess-4403637724796131416", "file": "dap_test.go", "code": 1, "output": "/var/folders/x4/wv98pc6d38n0ykn769h63jjw0000gn/T/ultestg8sv6o5y/dap_test_go/dap_test_go_out"}
19:51:49 | DEBUG | Thread-1 | __init__.py:_register_result:292 | Registering TestFailure-4403637724796131416 as exited with result {"id": "TestFailure-4403637724796131416", "file": "dap_test.go", "code": 1, "output": "/var/folders/x4/wv98pc6d38n0ykn769h63jjw0000gn/T/ultestg8sv6o5y/dap_test_go/dap_test_go_out"}
19:51:49 | DEBUG | MainThread | __init__.py:_present_output:109 | Showing dap_test.go output
19:51:49 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:78 | Finished job with group dap_test.go
19:51:49 | DEBUG | MainThread | __init__.py:_present_output:109 | Showing TestSuccess-4403637724796131416 output
19:51:49 | DEBUG | MainThread | __init__.py:_present_output:109 | Showing TestFailure-4403637724796131416 output
Colorscheme
What is the colorscheme you are using on the nvim screenshot ??
It would be helpful 🥰
ImportError when looking for Literal or Protocol in Python 3.7 typing
error caught in notification handler 'b'/home/michael/.local/share/nvim/site/plugged/vim-ultest/rplugin/python3/ultest:function:_ultest_update_positions' [[b'nvim/.config/nvim/init_plug.vim']]'
Traceback (most recent call last):
File "/home/michael/.local/lib/python3.7/site-packages/pynvim/plugin/host.py", line 145, in _on_notification
handler(*args)
File "/home/michael/.local/lib/python3.7/site-packages/pynvim/plugin/host.py", line 89, in _wrap_delayed_function
self._discover_functions(plugin, module_handlers, path, False)
File "/home/michael/.local/lib/python3.7/site-packages/pynvim/plugin/host.py", line 220, in _discover_functions
for _, fn in inspect.getmembers(obj, predicate):
File "/usr/lib/python3.7/inspect.py", line 341, in getmembers
value = getattr(object, key)
File "/home/michael/.local/share/nvim/site/plugged/vim-ultest/rplugin/python3/ultest/__init__.py", line 76, in handler
from .handler import HandlerFactory
File "/home/michael/.local/share/nvim/site/plugged/vim-ultest/rplugin/python3/ultest/handler/__init__.py", line 8, in <module>
from ..models import File, Namespace, Position, Result, Test, Tree
File "/home/michael/.local/share/nvim/site/plugged/vim-ultest/rplugin/python3/ultest/models/__init__.py", line 3, in <module>
from .file import File
File "/home/michael/.local/share/nvim/site/plugged/vim-ultest/rplugin/python3/ultest/models/file.py", line 2, in <module>
from typing import List, Literal
ImportError: cannot import name 'Literal' from 'typing' (/usr/lib/python3.7/typing.py)
Describe the bug
Literal and Protocol weren't added to typing until 3.8
To Reproduce
install vim-ultest on a system with Python 3.7
Additional context
vim-ultest/rplugin/python3/ultest/models/file.py
vim-ultest/rplugin/python3/ultest/models/namespace.py
vim-ultest/rplugin/python3/ultest/models/tree.py
vim-ultest/rplugin/python3/ultest/models/tree.py
all attempt to import either Literal or Protocol from typing. both were added in 3.8. you can find them in typing_extensions, though. so this code replacing the import (for Literal or Protocol where appropriate) in those files seems to work after typing_extensions is installed via pip
try:
from typing import Literal
except ImportError:
from typing_extensions import Literal
Issue running `UltestDebugNearest` with Go
Describe the bug
Setting a breakpoint in a Golang test and then running :UltestDebugNearest results in:
error caught in async handler '/Users/awalker/.local/share/nvim/plugged/vim-ultest/rplugin/python3/ultest:function:_ultest_external_result [[{'namespaces': [], 'id': 'TestParseLoginMethodExtractionComplete-5127535966012300037', 'col': 1, 'name': 'TestParseLoginMetho
dExtractionComplete', 'line': 29, 'type': 'test', 'running': 0, 'file': 'services/scheduler/upload/login_method_extraction_complete_test.go'}, 0, '/var/folders/hh/nbqckpb91qv7t2q3n8kcgqt022nfxk/T/nvimwKMAye/2']]'
Traceback (most recent call last):
File "/Users/awalker/.local/share/nvim/plugged/vim-ultest/rplugin/python3/ultest/__init__.py", line 114, in _external_result
return self.handler.external_result(*args)
File "/Users/awalker/.local/share/nvim/plugged/vim-ultest/rplugin/python3/ultest/handler/__init__.py", line 90, in external_result
raise ValueError(f"Unknown file {file_name}")
ValueError: Unknown file 0Logs:
1 │ 16:58:37 | INFO | MainThread | logging.py:create_logger:98 | Logger created
2 │ 16:58:37 | DEBUG | MainThread | __init__.py:__init__:41 | Handler created
3 │ 16:58:37 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:57 | Starting job with group update_positions
4 │ 16:58:37 | INFO | Thread-1 | tracker.py:_async_update:52 | Updating positions in services/scheduler/upload/login_method_extraction_complete_test.go
5 │ 16:58:37 | DEBUG | Thread-1 | file.py:parse_file_structure:22 | Converted pattern {'test': ['\\v^\\s*func (\\w+)'], 'namespace': []} to {'test': [re.compile('^\\s*func (\\w+)')], 'namespace': []}
6 │ 16:58:37 | DEBUG | Thread-1 | tracker.py:_async_update:79 | New test services/scheduler/upload/login_method_extraction_complete_test.go found in services/scheduler/upload/login_method_extraction_complete_test.go
7 │ 16:58:37 | DEBUG | Thread-1 | tracker.py:_async_update:79 | New test TestParseLoginMethodExtractionComplete-5127535966012300037 found in services/scheduler/upload/login_method_extraction_complete_test.go
8 │ 16:58:37 | DEBUG | Thread-1 | tracker.py:_async_update:79 | New test TestProcessLoginMethodExtractionComplete-5127535966012300037 found in services/scheduler/upload/login_method_extraction_complete_test.go
9 │ 16:58:37 | DEBUG | Thread-1 | tracker.py:_remove_old_positions:122 | No tests removed
10 │ 16:58:37 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:77 | Finished job with group update_positions
11 │ 16:58:45 | ERROR | MainThread | logging.py:__deferred_flog:62 | Error name 'process_id' is not defined converting args to str f"Saving external stdout path '{output_path}' for test {process_id}"
12 │ 16:58:45 | DEBUG | MainThread | __init__.py:_register_started:272 | Registering TestParseLoginMethodExtractionComplete-5127535966012300037 as started
13 │ 16:59:20 | ERROR | MainThread | __init__.py:external_result:87 | Attempted to register test result for unknown file {file_name}
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The test runs and hits my breakpoint.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
my debug adapter config looks like this at the time of the test run
{
request= "launch",
dlvToolPath= "/Users/awalker/go/bin/dlv",
mode= "test",
type= "go",
program= "/Users/awalker/plaid/go.git/services/scheduler/upload",
args= {
[1] = "-test.run",
[2] = "TestParseLoginMethodExtractionComplete$",
},
}[go test]: Incorrrect test results being reported
I know from the debugging wiki there are some issues with go test due to it not returning 0/1 exit codes after completion but I'm filing an issue in the hopes that there is a way, like in the debug flow, to attach an output parser.
As an example if I run a go test file using a call to :Ultest it shows the test as failing even though the actual output shows success.
I'm happy to help contribute if this doesn't already exist and isn't too deep in the weeds of what vim-test ultimately controls.
QUESTION: Is there a way to jump to the next/prev failure in the Test Summary Window?
If so, how would one do it? I didn't see it documented.
Error "no notification handler registered" on diff
Describe the bug
Using vim-fugitive, the command ":Git difftool -y master" spams me several (4) times with the error message.
Comment #44 (comment) looks similar
no notification handler registered for "/Users/myuser/.local/share/nvim/site/pack/packer/start/vim-ultest/rplugin/python3/ultest:function:_ultest_update_positions"
Enabling debug logs shows nothing, no matter if the command is started manually or via commandline (ULTEST_LOG_LEVEL=DEBUG ULTEST_LOG_FILE=vim-ultest.log nvim -c ":Git difftool -y master")
To Reproduce
:Git difftool -y
Expected behavior
No error
Screenshots
n/a
Additional context
n/a
Support for test#strategy?
vim-test's test#strategy option lets you execute the test in different execution environments. AFAIK ultest only supports output via floating window. Is it possible to have the same behavior in ultest?
[Bug] Incorrect PASS sign indicator when using dynamic string in suite description
Describe the bug
Hey @rcarriga 👋 !
First of all, great plugin! It's making it real easy to use vim-test. I'm using it with jest in an Angular project and it's working great so far. I did run into an issue though: When trying to use dynamic values in the string describing my test suite/case, the plugin fails to mark a failed test as failed. My guess is there is some sort of namespacing issue there. Please see the following snippet, and the attached screenshots bellow showing the faulty behavior. Thanks!
// src/test.spec.ts
export class MyComponent {
// ...
}
describe(MyComponent.name, () => {
test('this shows as OK even tho it fails...', () => {
expect(false).toBeTruthy();
});
});
describe('MyComponent_NameString', () => {
test('this works as expected', () => {
expect(false).toBeTruthy();
});
});vim-ultest.log
13:58:40 | INFO | MainThread | logging.py:create_logger:101 | Logger created
13:58:40 | DEBUG | MainThread | __init__.py:__init__:43 | Handler created
13:58:40 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:58 | Starting job with group update_positions
13:58:40 | INFO | Thread-1 | tracker.py:_async_update:55 | Updating positions in src/test.spec.ts
13:58:40 | DEBUG | Thread-1 | file.py:parse_file_structure:25 | Converted pattern {'test': ['\\v^\\s*%(it|test)\\s*[( ]\\s*%("|\'|`)(.*)%("|\'|`)'], 'namespace': ['\\v^\\s*%(describe|suite|context)\\s*[( ]\\s*%("|\'|`)(.*)%("|\'|`)']} to {'test': [re.compile('^\\s*(?:it|test)\\s*[( ]\\s*(?:"|\'|`)(.*)(?:"|\'|`)')], 'namespace': [re.compile('^\\s*(?:describe|suite|context)\\s*[( ]\\s*(?:"|\'|`)(.*)(?:"|\'|`)')]}
13:58:40 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test src/test.spec.ts found in src/test.spec.ts
13:58:40 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test this_shows_as_OK_even_tho_it_fails___4051083889056447564 found in src/test.spec.ts
13:58:40 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test MyComponent_NameString4051083889056447564 found in src/test.spec.ts
13:58:40 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test this_works_as_expected6682587002160702406 found in src/test.spec.ts
13:58:40 | DEBUG | Thread-1 | tracker.py:_remove_old_positions:125 | No tests removed
13:58:40 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:78 | Finished job with group update_positions
13:58:54 | INFO | MainThread | __init__.py:run_nearest:125 | Running nearest test in src/test.spec.ts at line 0
13:58:54 | DEBUG | MainThread | __init__.py:_register_started:281 | Registering src/test.spec.ts as started
13:58:54 | DEBUG | MainThread | __init__.py:_register_started:281 | Registering this_shows_as_OK_even_tho_it_fails___4051083889056447564 as started
13:58:54 | DEBUG | MainThread | __init__.py:_register_started:281 | Registering MyComponent_NameString4051083889056447564 as started
13:58:54 | DEBUG | MainThread | __init__.py:_register_started:281 | Registering this_works_as_expected6682587002160702406 as started
13:58:54 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:58 | Starting job with group src/test.spec.ts
13:58:54 | DEBUG | Thread-1 | processes.py:run:50 | Starting test process src/test.spec.ts with command ['node_modules/.bin/jest', '--noStackTrace', '--no-coverage', '--', 'src/test.spec.ts'], cwd = None, env = None
13:58:57 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:57 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:57 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:57 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:57 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:59 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:59 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:59 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:59 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:59 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:59 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:59 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:59 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:59 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:59 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:59 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:59 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:59 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:59 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
13:58:59 | DEBUG | Thread-1 | processes.py:run:76 | Process src/test.spec.ts complete with exit code: 1
13:58:59 | INFO | Thread-1 | output.py:parse_failed:66 | Found failed test in output this shows as OK even tho it fails... in namespaces MyComponent › of runner javascript#jest
13:58:59 | INFO | Thread-1 | output.py:parse_failed:66 | Found failed test in output this works as expected in namespaces MyComponent_NameString › of runner javascript#jest
13:58:59 | DEBUG | Thread-1 | __init__.py:_register_result:292 | Registering src/test.spec.ts as exited with result {"id": "src/test.spec.ts", "file": "src/test.spec.ts", "code": 1, "output": "/var/folders/g2/bt7vcjrn0v30vvnxnvs2p3qc0000gp/T/ultestu6s6l2ee/src__test_spec_ts/src__test_spec_ts_out"}
13:58:59 | DEBUG | Thread-1 | __init__.py:_register_result:292 | Registering this_shows_as_OK_even_tho_it_fails___4051083889056447564 as exited with result {"id": "this_shows_as_OK_even_tho_it_fails___4051083889056447564", "file": "src/test.spec.ts", "code": 0, "output": "/var/folders/g2/bt7vcjrn0v30vvnxnvs2p3qc0000gp/T/ultestu6s6l2ee/src__test_spec_ts/src__test_spec_ts_out"}
13:58:59 | DEBUG | Thread-1 | __init__.py:_register_result:292 | Registering MyComponent_NameString4051083889056447564 as exited with result {"id": "MyComponent_NameString4051083889056447564", "file": "src/test.spec.ts", "code": 1, "output": "/var/folders/g2/bt7vcjrn0v30vvnxnvs2p3qc0000gp/T/ultestu6s6l2ee/src__test_spec_ts/src__test_spec_ts_out"}
13:58:59 | DEBUG | Thread-1 | __init__.py:_register_result:292 | Registering this_works_as_expected6682587002160702406 as exited with result {"id": "this_works_as_expected6682587002160702406", "file": "src/test.spec.ts", "code": 1, "output": "/var/folders/g2/bt7vcjrn0v30vvnxnvs2p3qc0000gp/T/ultestu6s6l2ee/src__test_spec_ts/src__test_spec_ts_out"}
13:58:59 | DEBUG | MainThread | __init__.py:_present_output:109 | Showing src/test.spec.ts output
13:58:59 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:78 | Finished job with group src/test.spec.ts
13:58:59 | DEBUG | MainThread | __init__.py:_present_output:109 | Showing MyComponent_NameString4051083889056447564 output
13:58:59 | DEBUG | MainThread | __init__.py:_present_output:109 | Showing this_works_as_expected6682587002160702406 output
To Reproduce
Copy the provided code snippet and run :Ultest on it.
Expected behavior
Plugin should handle dynamic values in suite/test descriptions correctly.
Screenshots
Additional context
$ vim -v
NVIM v0.5.0
Build type: Release
LuaJIT 2.1.0-beta3
Compilation: clang -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -O2 -DNDEBUG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/tmp/neovim-20210702-21950-fs4dxz/neovim-0.5.0/build/config -I/tmp/neovim-20210702-21950-fs4dxz/neovim-0.5.0/src -I/usr/local/include -I/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include -I/usr/local/opt/gettext/include -I/tmp/neovim-20210702-21950-fs4dxz/neovim-0.5.0/build/src/nvim/auto -I/tmp/neovim-20210702-21950-fs4dxz/neovim-0.5.0/build/include
Compiled by brew@iMac-Pro
Getting error when installing the plugin
Describe the bug
I add the following line to my ~/.vimrc:
Plug 'rcarriga/vim-ultest', { 'do': ':UpdateRemotePlugins' }
And I'm getting the following error:
Error detected while processing /home/farzad/.vim/plugged/vim-ultest/plugin/ultest.vim:
line 175:
E995: Cannot modify existing variable
To Reproduce
Add the line to ~/.vimrc and do :PlugInstall
Expected behavior
I shouldn't see any error (I think!)
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
I'm using neovim and vim-plug, my neovim version:
NVIM v0.4.4
Build type: Release
Being spammed with errors when opening a file as sudo
Describe the bug
I'm on Archlinux and opening sudo nvim /etc/pacman.conf (which is owned by root), and ultest is spamming me with errors. For every motion that I do, I'm getting an error:
Error detected while processing function ultest#handler#get_nearest_test[1]..<SNR>503_Call[3].._ultest_get_nearest_test[1]..remote#define#request:
line 2:
Error invoking '/home/farzad/.vim/plugged/vim-ultest/rplugin/python3/ultest:function:_ultest_get_nearest_test' on channel 10 (python3-rplugin-host):^@no request handler registered for "/home/farzad/.vim/plugged/vim-ultest/rplugin/python3/ultest:function:_ultest_get_nearest_test"
I didn't create a log, but let me know if that would help and I can try to create one.
To Reproduce
Open a file with sudo and see the errors
Expected behavior
Errors should be handled gracefully and not interfere with file navigation
No output
NVIM v0.5.0-dev+1385-g93f15db5d
No output is displayed.
Python, Pytest.
Step:
- Open the test file,
- run the test (:UltestNearest)
- try to display the output (:UltestNearest)
I expect the output of the ran test to be display in a floating window.
Log:
20:35:29 | INFO | MainThread | logging.py:create_logger:101 | Logger created
20:35:30 | DEBUG | MainThread | __init__.py:__init__:43 | Handler created
20:35:30 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:58 | Starting job with group update_positions
20:35:30 | INFO | Thread-1 | tracker.py:_async_update:55 | Updating positions in server/api/test/test_list_field_values.py
20:35:30 | DEBUG | Thread-1 | file.py:parse_file_structure:25 | Converted pattern {'test': ['\\v^\\s*%(async )?def (test_\\w+)'], 'namespace': ['\\v^\\s*class (\\w+)']} to {'test': [re.compile('^\\s*(?:async )?def (test_\\w+)')], 'namespace': [re.compile('^\\s*class (\\w+)')]}
20:35:30 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test server/api/test/test_list_field_values.py found in server/api/test/test_list_field_values.py
20:35:30 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test TestListProjectsFieldValues5844803339631356660 found in server/api/test/test_list_field_values.py
20:35:30 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test test_givenProject_thenReturnAllValues-957566468643009455 found in server/api/test/test_list_field_values.py
20:35:30 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test TestListProjectResourceFieldValues5844803339631356660 found in server/api/test/test_list_field_values.py
20:35:30 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test test_givenProjectPipes_thenReturnAllValues2789591621640477456 found in server/api/test/test_list_field_values.py
20:35:30 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test test_givenUnhandledResourceType_thenRaiseError2789591621640477456 found in server/api/test/test_list_field_values.py
20:35:30 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test test_givenInvalidField_thenRaiseError2789591621640477456 found in server/api/test/test_list_field_values.py
20:35:30 | DEBUG | Thread-1 | tracker.py:_async_update:82 | New test test_givenHanledResource_thenReturnValues2789591621640477456 found in server/api/test/test_list_field_values.py
20:35:30 | DEBUG | Thread-1 | tracker.py:_remove_old_positions:125 | No tests removed
20:35:30 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:78 | Finished job with group update_positions
20:35:39 | INFO | MainThread | __init__.py:run_nearest:125 | Running nearest test in server/api/test/test_list_field_values.py at line 30
20:35:39 | DEBUG | MainThread | __init__.py:_register_started:281 | Registering test_givenProjectPipes_thenReturnAllValues2789591621640477456 as started
20:35:39 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:58 | Starting job with group test_givenProjectPipes_thenReturnAllValues2789591621640477456
20:35:39 | DEBUG | Thread-1 | processes.py:run:50 | Starting test process test_givenProjectPipes_thenReturnAllValues2789591621640477456 with command ['poetry', 'run', 'pytest', 'server/api/test/test_list_field_values.py::TestListProjectResourceFieldValues::test_givenProjectPipes_thenReturnAllValues'], cwd = None, env = None
20:35:41 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:41 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:41 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:41 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:41 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:50 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:50 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:50 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:50 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:50 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:50 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:50 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:50 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:50 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:50 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:50 | DEBUG | Thread-3 | handle.py:forward:85 | Writing data to output file
20:35:51 | DEBUG | Thread-1 | processes.py:run:76 | Process test_givenProjectPipes_thenReturnAllValues2789591621640477456 complete with exit code: 0
20:35:51 | DEBUG | Thread-1 | __init__.py:_register_result:292 | Registering test_givenProjectPipes_thenReturnAllValues2789591621640477456 as exited with result {"id": "test_givenProjectPipes_thenReturnAllValues2789591621640477456", "file": "server/api/test/test_list_field_values.py", "code": 0, "output": "/tmp/ultest0us1r641/server__api__test__test_list_field_values_py/test_givenProjectPipes_thenReturnAllValues2789591621640477456_out"}
20:35:51 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:78 | Finished job with group test_givenProjectPipes_thenReturnAllValues2789591621640477456
The plugin is amazing btw!
Q: Is it possible to scroll through the result?
Hi,
First of all thanks for the plugin, I started using and I really like it.
I had aquestion about tests that have very long output e.g. tests in typescript for the front end that generate a html body when they fail.
When I run a test similar to the aforementioned one, I can see some of the output but not all of it and I couldn't figure out how to check the rest of the output since I don't know how to scroll through the output of a test.
I'm not using any configuration for either vim-test or vim-ultest. I'm using them out of the box
If you need any more input please let me know.
Thanks in advance.
Test in camelcase won't run
Describe the bug
Test won't run if name of test is in camelcase.
18:57:48 | INFO | MainThread | logging.py:create_logger:98 | Logger created
18:57:48 | DEBUG | MainThread | __init__.py:__init__:41 | Handler created
18:57:48 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:57 | Starting job with group update_positions
18:57:48 | INFO | Thread-1 | tracker.py:_async_update:52 | Updating positions in test_token.py
18:57:48 | DEBUG | Thread-1 | file.py:parse_file_structure:22 | Converted pattern {'test': ['\\v^\\s*%(async )?def (test_\\w+)'], 'namespace': ['\\v^\\s*class (\\w+)']} to {'test': [re.compile('^\\s*(?:async )?def (test_\\w+)')], 'namespace': [re.compile('^\\s*class (\\w+)')]}
18:57:48 | DEBUG | Thread-1 | tracker.py:_async_update:79 | New test test_token.py found in test_token.py
18:57:48 | DEBUG | Thread-1 | tracker.py:_remove_old_positions:122 | No tests removed
18:57:48 | DEBUG | Thread-1 | __init__.py:_handle_coroutine:77 | Finished job with group update_positions
18:57:52 | INFO | MainThread | __init__.py:run_nearest:125 | Running nearest test in test_token.py at line 0
18:57:58 | INFO | MainThread | __init__.py:run_nearest:125 | Running nearest test in test_token.py at line 1
I am using djangotest as the python runner
To Reproduce
Create a test, and name it with camelcase in a django project, and try to run it.
For example:
This won't run.
def testSomething:
self.assertEqual(True, True)This will run
def test_something:
self.assertEqual(True, True)Expected behavior
As it runs as expected with vim-test, I would expect it to be run with vim-ultest as well.
Also while I am here, I have a simple question as well:
Is it possible to clear the icons after running tests? Couldn't figure out how to do this
Opening a new file causes E484: Can't open file
Describe the bug
Opening a new file causes the following error: (this does not apply to already existing files)
:e test.js Error detected while processing function <SNR>52_MonitorFile[4]..test#test_file[1]..test#determine_runner[9]..test#base#t
est_file[1]..test#javascript#denotest#test_file:
line 5:
E484: Can't open file test.js
Press ENTER or type command to continue
If you press enter then the file is opened as expected.
This only applies to some file types, for example: js, vim, php. File like lua, test work just fine. I'm assuming it only applies to files with a registered test runner.
Logs:
10:22:06 | INFO | MainThread | logging.py:create_logger:71 | Logger created
10:22:06 | DEBUG | MainThread | __init__.py:__init__:40 | Handler created
10:22:11 | INFO | MainThread | logging.py:create_logger:71 | Logger created
10:22:11 | DEBUG | MainThread | __init__.py:__init__:40 | Handler created
To Reproduce
nvim -u NORC
:e test.js # open a new file
Expected behavior
No error should occur. Should simply open the new file.
Additional context
Neovim version: NVIM v0.5.0-dev+1186-g8665a96b9 (built from master with Release)
vim-ultest and vim-test updated to latest
Python3 checkhealth:
## Python 3 provider (optional)
- INFO: Using: g:python3_host_prog = "/usr/bin/python3"
- INFO: Executable: /usr/bin/python3
- INFO: Python version: 3.8.5
- INFO: pynvim version: 0.4.3
- OK: Latest pynvim is installed.
Using latest version of vim-test and vim-ultest as of this writing.
Removing ultest fixes this issue.
Thank you for this awesome plugin! Hope you can fix this minor issue:)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.