rcarriga / vim-ultest Goto Github PK
View Code? Open in Web Editor NEWThe ultimate testing plugin for (Neo)Vim
License: MIT License
The ultimate testing plugin for (Neo)Vim
License: MIT License
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
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).
The title speaks of itself. Thank you for the plugin.
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?
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.
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.
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.
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:
What is the colorscheme you are using on the nvim screenshot ??
It would be helpful ๐ฅฐ
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.
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
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
.
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.
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
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
To Reproduce
Steps to reproduce the behavior:
vim-ultest
with packer
pynvim
in system interpreterpytest
and activate itExpected 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.
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.
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 0
Logs:
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$",
},
}
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
.
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
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
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'
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
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
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!
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
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
: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
clearmatches
to add it a parameter: https://github.com/neovim/neovim/pull/12325/files#diff-2edf914db40ccdd12cdf8d7e236fe3f4d8323ad43aa300f92720afda81ebae1aclearmatches
in the eval table in Neovim v0.4.4: https://github.com/neovim/neovim/blob/release-0.4/src/nvim/eval.lua#L66clearmatches
the plugin works but I don't know what side effects this could have.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.
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
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
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.
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
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
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
nvim -u NORC
:e test.js # open a new file
No error should occur. Should simply open the new file.
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:)
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!
NVIM v0.5.0-dev+1385-g93f15db5d
No output is displayed.
Python, Pytest.
Step:
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!
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
.vim
filevim-ctrlspace
menuvim-ctrlspace
Expected behavior
There shouldn't be any errors!
If so, how would one do it? I didn't see it documented.
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
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_sign
g:ultest_fail_sign
g:ultest_running_sign
g: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+003FDescribe 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.
Additional context
Thanks for the great plugin! Let me know if you need any more information.
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?
Describe the bug
No output whatsoever when testing an Elixir ExUnit case.
To Reproduce
Steps to reproduce the behavior:
ULTEST_LOG_LEVEL=DEBUG ULTEST_LOG_FILE=ultest.log nvim test/foo_test.exs
: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.
Additional context
Add any other context about the problem here.
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?
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
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
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
.
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.)
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?
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 == b
Place the cursor on either test function and execute :Ultest
or :UltestNearest
.
Additional context
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.