Question: how does your testing setup work?

[AdamWagner]

Hi @andweeb !

I've been researching how folks approach testing Hammerspoon-related projects. The process has been more challenging than expected: ki is one of the only Hammerspoon projects I've found with a substantial test setup.

Context My project (https://github.com/AdamWagner/stackline) has grown to the point that the majority of development time is spent following-up on collateral damage caused by a (seemingly) small, unrelated change. Even when I catch it early, the side effects often ripple until I'm troubleshooting something several levels removed from the original intent. I need to add tests!

stackline makes heavy use of hs.window. Ideally, I would like to have a handful of fixtures, each representing the complete window state of a test scenario.

Questions about testing in ki

Mocking

How does https://github.com/andweeb/ki/blob/master/spec/mock-hammerspoon.lua work? It seems that most of the mocked methods are no-ops, and I don't understand why that is useful. But, I'm sure I'm missing something.

Not invented here (?)

It doesn't seem like you're using a test framework such as busted. Is that correct? Did you author all of the describe(…) functions that perform the actual tests? Is all of that source code in this repo?

Anything else you think could help

As you can see, my starting point is just past lua-noob, so anything you think might be helpful surely will be :-)

[andweeb]

Hi @AdamWagner 👋 These are good questions! I did the same research while creating Ki and found there weren't many resources or conventions, at least at the time. So hopefully this helps!

Mocking The mock-hammerspoon.lua file contains a hs object with a subset of its methods stubbed out (only the ones used in my project). This is basically what you would call a manual mock in Jest or a "hand-rolled" mock. It's not useful by itself, but you can see at the bottom of the file I expose a factory function to use in the test files to not only have a "default" Hammerspoon environment so tests don't break but also be able to mock a subset of the methods differently for individual test suites.

Not invented here (?) I do use busted! You can see in my Makefile here I leverage their tagging system and use their framework in my tests, and use LuaCov with luacov-console for code coverage and console reporting.

Anything else you think could help Just an FYI if you'll be using my tests as reference, in my unit tests I've adopted the convention of using table-driven tests, a popular model of testing in Go. Many of the conventions I used in this project are borrowed from outside of the realm of Lua, so I wouldn't consider my tests as the golden standard, but they've just worked well for me!

Let me know if you have any other questions, and/or suggestions too!

Also, sick project you got there :) Looks like I gotta try out yabai and stackline.

[AdamWagner]

Thanks so much for the helpful response, especially since I probably should've been able to find the answers to a lot of these in the source (always obvious in hindsight :-)

The link to the Jest docs was quite helpful. I should have said that I'm not just a noob in lua, but in general; this will be my first time actually writing tests for a side project.

I really like the look of the table-driven tests. Easy to read. I'll definitely be using your work here as a model. Thanks!