Testing framework?

[eshrh]

I'm starting to feel that the project has grown big and complex enough that maybe a test framework would be of use. It's much harder to make changes and refactor code if I'm not sure if something will break.

I'm interested in writing a series of unit tests using ert, please let me know if this is a good idea.

[DogLooksGood]

It's definitely a good idea. Probably we can make a list, about all the featuers, commands we care, since meow has some deprecated stuff, and useless codes. we only test thing on the list, and mark all others as deprecated, or remove them. How do you think?

When we actually adding test, I think it's better to have a stable code base. I think the feature of Meow is stable already, but the code is a bit complex, we just need a housekeep.

[eshrh]

I agree. Right now i was planning on just going through meow-tutor and testing everything that it uses, before writing functional tests for deeper things like keypad. It's probably better to stay organized since the tutor doesn't touch every function.

I think there will also be a fair bit of refactoring that needs to happen to make some functions testable. For example, meow-find and meow-till should have optional args that take a character instead of always prompting.

I'll come up with a list in some time (lots of code to read), and then maybe I'll start working on a branch.

[DogLooksGood]

Yeah, I'd like to begin with what Meow should do, and what Meow shouldn't. This can help Meow keep simple, it's important for other projects / configuration that relies on Meow.

In normal mode, Meow should take care of:

• "selection" = move + select + thing + direction
• editing operation: insert, delete, swap, etc

In motion mode, Meow should take care of solving keybinding conflicts.

In keypad mode, Meow should take care of command execution.

In beacon mode, Meow should take care of multiedit.

How do you think of this?

[eshrh]

sounds good. is it really necessary to test the set of functions that basically only call execute a keyboard macro? I feel like it's a waste of time since they are so unlikely to break.

[DogLooksGood]

Agree, no need to write tests for those.

[leira]

What about something like the regression tests in Kakoune? Each tests are essentially just 4 files:

1. in: the input text to be edited.
2. cmd: the kakoune key/command sequence to apply on in.
3. out: the expected result after applying cmd.
4. rc: some pre-setup before applying cmd.

[ParetoOptimalDev]

Note that you'll likely want to copy what evil does for it's testing or even take things a step further and use tmux for various horrible reasons I cannot recall. If this makes no sense, I can try to elaborate... but wanted to share this knowledge in case its necessary.

[trev-dev]

There is also buttercup, which seems to have more "modern" unit testing abstractions: https://github.com/jorgenschaefer/emacs-buttercup

Testing is easier to do if it's done from the beginning, but there's no reason why we can't start something if we haven't already. 100% of all functions would be nice but it's always aspirational :)

[jgarte]

I think it would be awesome for meow to have a test suite and why I accidentally opened #452 before seeing #230

we only test thing on the list, and mark all others as deprecated, or remove them. How do you think?

451 Maybe we can start by writing a unit test for meow-raise-sexp.

I think this is a greaet idea to have a ttest suite for meow.

I think that vis has a great test suite that we should maybe look at for inspiration:

https://github.com/martanne/vis-test

I think there will also be a fair bit of refactoring that needs to happen to make some functions testable. For example, meow-find and meow-till should have optional args that take a character instead of always prompting.

@eshrh That refactor sounds like a great idea in order to support testing. It reminds me of refactoring a function in order to not have to introduce patching/mocking into your codebase.

What's the latest progress on this?