for norns in particular, there is the problem that many realtime processes are hard to unit-test. by “hard” i mean they require super-super-intensive mocking and results analysis. that said, certainly it’s a good idea for, ehh, “BL” and “UI.”
you can hear me in the hackalong, muttering about unit tests being a good idea as i type ad-hoc tests into the REPL for a very simple Pattern module. certainly for small BL pieces like this its clear that putting test functions in the module code is a good idea.
i guess i think that a test-running framework is the least important part of the process, the most important ones being 1) module/unit/class architecture, 2) the tests themselves.
things like gbuf or tabutil have to be included
tabutil.lua, like many norns libs, has no dependencies and can be trivially included in any lua environment.
gridbuf.lua, like many other norns libs, uses norns system globals, and talks to hardware and/or external processes. this is where the effort of mocking really blows up and is arguably not worth it (e.g. mocks themselves can have bugs, &c &c), instead break out unit testable components and stick to functional testing for realtime interaction bits.