Skip to content

Add operator tests (delete, yank, change)#1

Draft
badranX wants to merge 8 commits intothomie:masterfrom
badranX:dev-operators
Draft

Add operator tests (delete, yank, change)#1
badranX wants to merge 8 commits intothomie:masterfrom
badranX:dev-operators

Conversation

@badranX
Copy link

@badranX badranX commented May 25, 2025

Thanks for this tool, it helped me a lot.

These are some tests related to commands like diw, da), yy, dd ... etc

I used $ESC$ESC instead of expect NOR or delay. It's working on my Linux. I probably need to change that.

I'm using this particularly to validate this PR: usagi-flow/evil-helix#103

@thomie
Copy link
Owner

thomie commented May 27, 2025

Hi,

It's great you're adding new tests.

I just ran shelltest test_operators/ on your branch, and I got the following 2 failures (with Vim):

:test_operators/space_yank.test:1: [Failed]
Command (at line 5):
./bin/keymaptest vim 'send " "' 'send yy' 'send j' 'send \"+p'
Expected stdout: 
foo
bar
foo

Got stdout:      
foo
bafoor

:test_operators/space_yank.test:2: [Failed]
Command (at line 15):
./bin/keymaptest vim 'send " "' 'send 2yy' 'send \"+p'
Expected stdout: 
foo
foo
bar
bar

Got stdout:      
fofooo
bar

I didn't look any further yet, but that probably needs investigating.

The other thing I noticed is that some tests take a long time to complete (10 seconds). These are some examples:

shelltest test_operators/delete_operator.test -i6 # 7,8,9,10 as well
shelltest test_operators/undo_operator.test -i1
shelltest test_operators/yank_operator.test -i6  # 7,8,9,10 as well

Are those tests slow for you as well?

I remember I needed expect to fix these type of hangs.

If we ever add this testsuite to the evil-helix CI, it would be nicer if at least the Vim tests ran reasonably fast.

@badranX
Copy link
Author

badranX commented May 28, 2025

Oh, the failed tests are evil-helix only tests. I renamed the file to indicate that. I was thinking we can add features to evil-helix when they don't have conflict with Vim. The test is for SPACE+[yank operations]. If you are against that, I can drop them (maybe put them in a separate repo).

Are those tests slow for you as well?

I also have a 10 seconds delay on Vim. It looks like expect has a default timeout of 10 seconds. I think the reason is that Vim doesn't have NOR. Something like expect NOR will take the full 10 seconds delay.

Another thing: expect doesn't fail the test after timeout/not-found, which makes it useless as a test. It's also very slow. Maybe the tests should focus on input/output, or maybe we can wrap it in a function that fails on timeout/not-found (not sure how to do that).

@thomie
Copy link
Owner

thomie commented May 28, 2025

Oh, the failed tests are evil-helix only tests.

Ok, that's fine.

I also have a 10 seconds delay on Vim. It looks like expect has a default timeout of 10 seconds. I think the reason is that Vim doesn't have NOR. Something like expect NOR will take the full 10 seconds delay.

expect NOR only "works" when you move FROM visual/insert/replace mode TO normal mode. There needs to be a change of words on the screen that we can detect. If vim is currently in normal mode, then 'expect NOR' doesn't do anything and will indeed timeout after 10 seconds.

In this test:

# 6. di$ESC
<
(foo)
$ ./bin/keymaptest vim 'send di' 'send $ESC' 'expect NOR' 
(foo)
>= 0

The 'send $ESC' 'expect NOR' doesn't add anything and I believe you can remove them.

If you look at

send $ESC
sleep 0.1
send :wq!\r
expect eof
, you see every test already ends with ESC.

I didn't look at the other tests yet.

@badranX
Copy link
Author

badranX commented May 28, 2025

I removed expect completely. I relied only on the expected output text. A bit more messy tests but faster.

I need to test with $ESC on some commands and make sure to switch back to normal mode and also back to visual mode without bugs. I introduced a procedure in the script, that does escape with 0.1 second delay to avoid using expect.

Edit: Sorry, you wrote

expect NOR only "works" when you move FROM visual/insert/replace mode TO normal mode.

Then the added escape procedure is probably useless. I'll try to improve this Draft later. Maybe after I get some feedback on usagi-flow/evil-helix#103.

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

Successfully merging this pull request may close these issues.

2 participants