Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Perpetually scheduling tests #474

Closed
kylechui opened this issue Mar 21, 2023 · 7 comments
Closed

Perpetually scheduling tests #474

kylechui opened this issue Mar 21, 2023 · 7 comments

Comments

@kylechui
Copy link

kylechui commented Mar 21, 2023

Hi there, I recently switched over to lazy.nvim for package management (which I suspect is the reason), and now my plenary test suite no longer runs. Here's the output for the testing window:
image

And I've been using this command to trigger it (it just runs the tests on the correct folder, as long as you're in the git project):

map("n", "<Leader>t", function()
    local cur_path = vim.fn.expand("%:p:h")
    while cur_path and vim.fn.finddir("tests", cur_path) == "" do
        cur_path = cur_path:match("(.*)/.*")
    end

    if cur_path then
        require("plenary.test_harness").test_directory(cur_path .. "/tests", {
            minimal_init = cur_path .. "/tests/minimal_init.lua",
        })
    end
end, {
    silent = true,
    buffer = true,
})

Any advice would be greatly appreciated (plenary is loaded in when I trigger this keymap; I tried both lazy-loading with telescope as well as forcing it to load on startup, but neither resolved the issue).

It appears that the regular <Plug>PlenaryTestFile still works for individual files though.

@jghauser
Copy link

I have the same issue, but have installed plenary via home-manager in nixos. I thought my issue was related to what i saw in #319, so I posted there, but I'm not sure about that anymore.

@matu3ba
Copy link
Contributor

matu3ba commented Apr 1, 2023

As workaround/more clean test environment, you can add tests/minimal.lua with

vim.opt.rtp:append(".")
vim.opt.rtp:append("../plenary.nvim")
vim.cmd.runtime { "plugin/plenary.vim", bang = true }

and use nvim --headless --noplugin -u tests/minimal.lua -c "PlenaryBustedDirectory tests/ {minimal_init = 'tests/minimal.lua'}" with plenary.nvim checked out in $HOME/projects/ and dev = true set for the plugin.

@matu3ba
Copy link
Contributor

matu3ba commented Apr 2, 2023

Probably the same problem appears on using

local add_cmd = vim.api.nvim_create_user_command
add_cmd('CheckLua', function()
  local os_env_path = os.getenv 'PATH'
  local tests_run = plenary.job:new({ command = 'nvim', args = { '--headless', '--noplugin', '-u', 'tests/minimal.lua', '-c', [["PlenaryBustedDirectory tests/ {minimal_init = 'tests/minimal.lua'}"]] }, env = { ["PATH"] = os_env_path } })
  tests_run:sync()
  print(vim.inspect.inspect(tests_run:result()))
end, {})
:CheckLua                                                                                                                                   
Error executing Lua callback: .../.local/share/nvim/lazy/plenary.nvim/lua/plenary/job.lua:499: 'nvim --headless --noplugin -u tests/minimal.lua -c "PlenaryBustedDirect
ory tests/ {minimal_init = 'tests/minimal.lua'}"' was unable to complete in 5000 ms                                                         
stack traceback:                                                                                                                            
        [C]: in function 'error'                                                                                                            
        .../.local/share/nvim/lazy/plenary.nvim/lua/plenary/job.lua:499: in function 'wait'                                                 
        .../.local/share/nvim/lazy/plenary.nvim/lua/plenary/job.lua:453: in function 'sync'                                                 
        /home/user/.config/nvim/lua/my_cmds.lua:385: in function </home/user/.config/nvim/lua/my_cmds.lua:376>

From cli it just works with env -i PATH="$PATH" nvim --headless --noplugin -u tests/minimal.lua -c "PlenaryBustedDirectory tests/ {minimal_init = 'tests/minimal.lua'}"

Starting...Scheduling: tests/example_spec.lua

========================================
Testing:        /home/user/projects/buf.nvim/tests/example_spec.lua
Success ||      Test example Test can access vim namespace
Success ||      Test example Test giveme123

Success:        2
Failed :        0
Errors :        0
========================================

@IlyasYOY
Copy link

IlyasYOY commented Apr 10, 2023

I faced freezing tests in my project. There you can find minimal.lua for lazy.nvim.

Missing dependencies caused the problem. I have require out of describe block. I moved the logic into the describe and tests started to fail with stacktrace. I'd recommend you to move require inside the describe (in case you don't have it so).

@matu3ba
Copy link
Contributor

matu3ba commented May 7, 2023

A simpler reproduction only with rg:

  local job = Job:new {
    command = "rg",
    args = { "test" }, -- does not work
  }
  job:sync()

Must run this in a subdir, not $HOME. Then it makes no difference with cwd = vim.loop.cwd().

UPDATE: Looks like ripgrep is unable to get the correct cwd and might default to $HOME. Might be the same cause here, that cwd is not set:

  local job = Job:new {
    command = "rg",
    args = { "test", "." }, -- works
  }
  job:sync()

Adding cwd = vim.loop.cwd() does neither fix the issue.

@kylechui
Copy link
Author

kylechui commented Jun 6, 2023

I faced freezing tests in my project. There you can find minimal.lua for lazy.nvim.

Missing dependencies caused the problem. I have require out of describe block. I moved the logic into the describe and tests started to fail with stacktrace. I'd recommend you to move require inside the describe (in case you don't have it so).

I just checked my own tests and I'm pretty sure all of my require calls are inside describe blocks, but it still seems to hang for me :/

@kylechui
Copy link
Author

kylechui commented Jun 3, 2024

I think this was an issue with not properly setting up lazy within the unit tests; this fix worked for me (I took the config from one of folke's plugins, but I don't remember which).

@kylechui kylechui closed this as completed Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants