It's way overdue; ideally we want to run tests inside the client to make sure the API interactions are working as expected.

Not sure if LuaUnit or similar frameworks will run in the modified Lua environment, but if all else fails I could adapt the UnitTester addon I wrote for another project. Offline testing might also be an option, though mocking the WOW API seems like a lot of unnecessary work when we can just access it directly.

Once this is done, refactoring the legacy codebase can be tackled. This is mandatory if we want to fix long-standing issues such as the LibQTip/UI loading time disaster and related "script ran too long" errors. Just refactoring away at the Core without having tests to rely on has a good probability of breaking absolutely everything, so that doesn't sound very appealing.

I've looked into busted first, and here's my thoughts so far:

• It's made available only through luarocks (big yikes)
• luarocks is practically impossible to get working on Windows, and IME it just doesn't work unless you want to expend a truly obscene amount of effort on something that should be simple and painless (hello npm)
• Therefore, requiring this to be used for testing would increase the barrier to entry and cause a lot of misery for anyone who tried and isn't a Linux user - which in the WOW world likely describes "most people"
• Requiring nothing but a simple lua interpreter executable (lua5.1 or luajit) seems far lower of a demand
• For the CI pipelines it really doesn't matter, but developers should be able to run tests locally on Windows

TL;DR: Using busted would be a liability instead of an asset due to its heavy reliance on luarocks. No dice.

Got LuaUnit working in just a minute, though I've used it before (years ago). I'm not sure if it can be embedded into the WOW client's Lua environment, but I don't think so since it uses functions like require() that we'd have to mock.

Alright, I was able to mock a bunch of functions that we can't use, like math.randomseed or os.clock, but whether that's enough remains to be seen. Update: It's not, there are obscure errors inside the LuaUnit code.

I just discovered https://github.com/Jaliborc/WoWUnit, so maybe we can use that for integration test instead.

Which one would work best? There's busted for a BDD approach, and LuaUnit for a more classical, TDD approach.

The former seems to have more community participation, but uses the awkward syntax that's common in the JavaScript world, too.

Edit: I don't think it can run inside the WOW client due to using LuaRocks, but I suppose we could still use it for unit/component-level tests, and either LuaUnit or a different solution (WoWUnit addon? Not sure if it still works) for integration and system-level tests.