plenary.nvim
plenary.nvim copied to clipboard
plenary.busted more compact output
@tami5 s wish :) For
Fail || depm.use installs and setup filetypes plugins
/home/tamibam/repos/depm.nvim/tests/auto/depm_spec.lua:65: should have add a Filetype autocmd.
Expected objects to be the same.
Passed in:
(boolean) false
Expected:
(boolean) true
stack traceback:
/home/tamibam/repos/depm.nvim/tests/auto/depm_spec.lua:65: in function 'test'
/home/tamibam/repos/depm.nvim/tests/auto/depm_spec.lua:29: in function </home/tamibam/repos/depm.nvim/tests/auto/depm_spec.lua:24>
To
Fail || depm.use installs and setup filetypes plugin `/.../auto/depm_spec.lua:65:`
Case: should have add a Filetype autocmd.
Passed in: (boolean) false
Expected: (boolean) true
Stack Traceback:
/home/tamibam/repos/depm.nvim/tests/auto/depm_spec.lua:65: in function 'test'
/home/tamibam/repos/depm.nvim/tests/auto/depm_spec.lua:29: in function </home/tamibam/repos/depm.nvim/tests/auto/depm_spec.lua:
Changes are:
- Normalize path an put on the same line.
- Print case if case is there requires changes in
luassertwhich we bundle so we can do it but i am not so sure if we should do that :) - Put the
Passed inandExpectedoutput on one line. Requires changes inluassert
Thats a somewhat good issue for newcommers :)
Yeah the test result output could be slicker. Here a dump from my end:
Scheduling: /Users/MateoPanadero/Repositories/factorsharp.nvim/lua/spec/solution_spec.lua
========================================
Testing: @/Users/MateoPanadero/Repositories/factorsharp.nvim/lua/spec/solution_spec.lua
[31mFail[0m || (get_parent_directory_path(path)) : Returns the path to the parent directory for *nix systems
...Repositories/factorsharp.nvim/lua/spec/solution_spec.lua:12: Expected objects to be equal.
Passed in:
(string) 'a/b/c'
Expected:
(string) 'a/b/d'
stack traceback:
...Repositories/factorsharp.nvim/lua/spec/solution_spec.lua:12: in function <...Repositories/factorsharp.nvim/lua/spec/solution_spec.lua:7>
[31mFail[0m || (get_parent_directory_path(path)) : Returns the path to the parent directory for Windows
./lua/solution.lua:7: attempt to perform arithmetic on local 'index_of_last_path_separator' (a nil value)
stack traceback:
./lua/solution.lua:7: in function 'get_parent_directory_path'
...Repositories/factorsharp.nvim/lua/spec/solution_spec.lua:19: in function <...Repositories/factorsharp.nvim/lua/spec/solution_spec.lua:14>
[32mSuccess: [0m 0
[31mFailed : [0m 2
[31mErrors : [0m 0
========================================
Tests Failed. Exit: 1
The failing spec:
local sut = require 'lua.solution'
describe("(get_parent_directory_path(path)) :", function()
describe("Returns the path to the parent directory", function()
it("for *nix systems", function()
local path = "a/b/c/"
local expected = "a/b/d"
assert.is_equal(expected, sut.get_parent_directory_path(path))
end)
it("for Windows", function()
local path = "a\\b\\c\\d"
local expected = "a\\b\\c"
assert.is_equal(expected, sut.get_parent_directory_path(path))
end)
end)
end)
@Mathijs-Bakker that looks good, I'd say path should be relative to current file so we can somehow attach gf to jump to the error.
Also perhaps
./factorsharp.nvim/lua/spec/solution_spec.lua:12
Expected objects to be equal:
Expected:
(string) 'a/b/d'
Received :
(string) 'a/b/c'
This is actual plugin behavior. I didn't do anything to it. It's just how it shows up on my end (MacOS).
In case of running the testfile itself - aka <Plug>PlenaryTestFile - the whole path with filename is redundant. The stack trace is giving us that info.
Something like below is very readable... It's probably better to break the lines of the 'descriptions' and 'it's' to prevent long lines/sentences. And preserve readability.
Tests: 2, Success: 1, Fails, 1, Errors: 0
get_parent_directory_path(path) : (description)
Returns the path to the parent directory (it)
for *nix systems: (it)
Expected objects to be equal.
Passed in:
(string) 'a/b/c'
Expected:
(string) 'a/b/d'
Stack traceback:
...Repositories/factorsharp.nvim/lua/spec/solution_spec.lua:12:
in function <...Repositories/factorsharp.nvim/lua/spec/solution_spec.lua:7>
~I don't know if it's really possible. As Busted generates the stdout?~
Oh thats very readable. Yes everything (I think) is generated by plenery, e.g. checkout plenary.nvim/lua/luassert/languages/en.lua you can play around there.
I'm currently addressing this... will submit a pr when ready.
:heart_eyes:
the wtf-rate is high on this one XD will take a while
Did i underestimate the task? :) Or do you need any help?
I've resolved and passed the initial issue. But that's not enough for my ideas. Want to achieve the output like Busted:
Which shouldn't (read: I expect to not) be a biggie... Boy, I was wrong XD
Anyways... still have some more reading/refactoring to do, to grasp plenary.testharness. And it's dependencies. Good part is that I saw some vim.api functions which I didn't knew the existence of. Which makes some Lua functions - that I wrote in other projects - redundant.
Ok, I have most things running... Which means the visual dots... And the failure and error output. Just like 'vanilla' Busted. I will do a 'draft' tomorrow.
@Conni2461 What's the reason to not implement the original Busted into this repo? Too much bloat?
Sounds good. We had it originally was not working good. Too much bloat sums it up great. Got replaced here: https://github.com/nvim-lua/plenary.nvim/pull/31
Can't wait for your draft :) Note you might have to rebase. I just did some bug fixing yesterday. https://github.com/nvim-lua/plenary.nvim/commit/116aedc7fb327eda6e7c05915f3d97088569c0e8