What

Refactor the PrinterSpec module to support Test Sets.
Each set will test an instance of PrinterOpts, i.e. a combination of fourmolu's customizations.

How

Define data types to represent a test case and a test set:

• A test case represents an input and the expected output.
• A test set contains:
  • An instance of PrinterOpts, which have the combination of options you want to test.
  • A label, e.g. "ormolu" for ormolu's default option.
  • A list of test cases.

This decreases the coupling between the code that defines the configs, examples and file list from the code that runs and checks the examples.

Why

See #49. Fourmolu now has a lot of options, and we need an easier way to test them properly.

With this change, testing a new combination of options should also be much easier.

I don't think this should necessarily be the final state, but IMO it's a step in the right direction.

See an example of adding a test suite for a new option in #102.

RFC and Possible Follow Ups

• I added a canBreakIdempotence boolean to the test set data type, because some of the customizations currently under review can do this (e.g. Automatic line breaking at specific limit #102, Do hang record constructors when turned on setting #103).

  • This is to avoid adding conditions for skipping the idempotence check inside checkExample, which shouldn't have any logic specific to an option.

• We could decouple things even more?

  • Some ideas:
    • Create a separate module for the test set configs and/or new data types.
    • Create separate Specs for each config.
    • Create subfolders for output files, instead of using suffixes.
    • This could make reusing files from other options a bit more confusing, but it would improve the examples directory structure.
  • Since we don't have that many test sets now, I don't think that working on these things is necessary, but I would love to get your thoughts about this.