We have a couple of different modules for making test cases, namely Module:UnitTests and Module:ScribuntoUnit, but these seem like a duplication of effort with Scribunto's native unit test framework. It would be nice to somehow expose the framework via mw.test or similar so that it can be used by modules. Having one "official" way to do unit testing should simplify development for module writers, and would make it easier to write how-to guides etc. for those new to coding.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T50176 Requested Scribunto/Lua built-in methods/functions (tracking) | ||
| Open | None | T103937 Expose TestFramework.lua to modules via a new test runner library |
Event Timeline
Comment Actions
Err, it already does expose the Lua part of it. But the test runner is
PHPUnit, which can't really be exposed.
If you want a test runner, IMO the task should be clarified that you need
something *new* rather than something *exposed*. There may already be a
task for that, BTW.
Comment Actions
The particular file that I was thinking about exposing was tests/engines/LuaCommon/TestFramework.lua. You're right that "exposing" was a bad choice of words, though, because there would need to be a new library to make tests using it runnable by modules on-wiki.
Thinking about this some more though, this would probably be a non-trivial amount of work for not all that much benefit, especially seeing as we would have to write tests for our new test library and make sure the existing tests didn't break.
Comment Actions
I was confusing the unit test stuff with mw.libraryUtil for some reason. Sorry.
testframework.deepToString is probably redundant to mw.dumpObject, except maybe for the bit where the latter honors tostring. testframework.deepEquals might be useful somewhere. The rest aren't useful without a test runner that uses that same data format.