Filesystem watcher

[ajacksified]

Automatically run tests when files are changed. cc @leafo

[ajacksified]

Implement busted watch, using whichever exists on the system:

• inotify-tools, linuxes
• fsevents-tools, osx

And print out a helpful error message about installing one of these if neither exists. Windows, use cygwin and inotify-tools

[DorianGray]

http://dereknewton.com/2011/05/monitoring-file-system-changes-with-powershell/ - for windows

[leafo]

Would be nice to get a cross-platform filesystem watch library out of this. I've used https://github.com/hoelzro/linotify on linux.

[DorianGray]

Agreed, it should be a separate library.

[DorianGray]

I've taken this out of the 2.0 release.

[johnae]

@leafo @DorianGray @ajacksified Some shameless self-promotion here but you might want to look at

https://github.com/johnae/spook

It is a relatively new project, works a bit like guard (ruby). It's written mostly in moonscript but it's all compiled down to a single binary. It will watch your files and run tests (or whatever you like really) in response.

[louwers]

Use entr it's cross-platform.

ls *.lua | entr busted

[alerque]

Personally I think the right answer here is "use a different tool". It would certainly be possible to build something into busted but it would also bring more dependencies and more cross platform issues. It would also inevitably not work for everybody and other tooling would continue to be used. I don't see what an "option dependency" approach where a command was only enabled if something else is installed would bring over just having somebody run entr instead.

The other major point I see here is that in Lua / Busted we don't really have any way of doing incremental build and testing. We have no idea whether modifications to X might affect test Y or Z or both. Even if we know what project input files changed all the tests need to be re-run — unless your project has some specific layout where tests are manually broken up to match components. Since that could be done any number of ways we don't really have a way to generalize it. Making people setup their own testing triggers seems like the best plan to me.

My personal use case usually looks like this:

$ git ls-files | entr -c busted --verbose

Of course I usually have a linter open in a sidebar terminal too:

$ git ls-files '*.lua' | entr -c luacheck -q /_

But of course depending on project layout and requirements everything can be tweaked.

2 more factors to throw in:

1. Although I'm an advocate of all testing being possible to run locally and remotely, more and more setups are relying on remote CI testing anyway. Busted v2.1.0 will ship a basic GH Action adding to the myriad of ways to run it in CI.

2. It might be easier to setup a new project that wrapped busted and invoked it based on input from a watch library than to build it into busted. That at least keeps busted available with a light dependency list while more specialized workflows could use a tool tailored to the live reload style usage a file system watcher would provide. c.f. spook noted above.

---

I'm willing to reevaluate if there are counter arguments in favor of building this into busted, but I'd recommend closing this as "not planned".