Published: 10.28.2020

In my free time when working on open source projects, I typically find myself working on build tools and CLI type projects. These kind of projects, unlike the web apps I help build by day, typically take a combination of a user configuration file and some source code, and then generates some sort of output from that.

For the Greenwood project, which is a site builder, the output of that project is going to be HTML, CSS and JavaScript, all based on the user's source code (e.g. markdown files). To help ensure we don't break anything as we go, and taking influence from webpack and how they setup their tests, the majority of the project's test coverage is predominently made up of test "cases"; wherein fixtures and files are used to recreate what a users folder structure might actually look like while using the tool. (I think this would fall under the umbrealla of BDD, but don't quote me on that)

In this way, given a user's config and content, Greenwood can ensure critical features are still working and validate behavior like:

  • Were the user's markdown files correctly converted to HTML?
  • Was their CSS and JavaScript bundled and optimized?
  • If they had a configuration file, were those options reflected in the output?

Gallinago is the standalone tool I created that allows one to essentially stub out an entire user's "workspace" and then run your CLI against it, and see (and test!) what the output is.

For example, if a user had a directory for their project like this in Greenwood:


The generated output should be something like this:


Combined with Mocha, Greenwood can run its CLI against a bunch of pre-scaffolded directories simulating different user configurations and content types, and ensure the correct output each time.

I think that's... Larry David gif

So, please feel free to try it out and let me know what you think! ✌️

© Owen Buckley /