Tests refactor

[kddnewton]

Okay so this is a big one. A couple of reasons for it:

• After seeing @johnschoeman's work on Jts ct ruby specs #209 and Jts blocks mini test #210, I wanted to make it easier to work in a test-driven manner.
• The test suite needed to be sped up. It was kind of all over the place and doing too many things.
• The tests were testing a lot of the same things in different places, and so weren't very reliable.

Here's what this PR does:

• Migrates all of the existing node tests into new unit tests in jest.
• Maintains a single parser child process so that it's much much faster to run (the full test suite is now around 10s). I actually think this may be a potential improvement for the parser in general (it's possible we could migrate this over to just be the regular parser).
• Remove the snapshots. At the end of the day there were too many to check and they were getting in the way. I really want to bring these back, but only in a full integration test capacity.

I want to write up some docs and start incorporating some of the open PRs into this work, but I figured I'd open this up now.

[localhostdotdev]

Remove the snapshots. At the end of the day there were too many to check and they were getting in the way. I really want to bring these back, but only in a full integration test capacity.

was curious about this, here is what I found useful to understand:

toMatchFormat: (format, config = {}) => checkFormat(format, format, config)

const checkFormat = (before, after, config) => {
  const options = Object.assign({}, { parser: "ruby", plugins: ["."] }, config);
  const actual = prettier.format(before, options);

  return {
    pass: actual === `${after}\n`,
    message: () => `Expected:\n  ${after}\nReceived:\n  ${actual}`
  };
};

ok, so it's checking for idempotence, quite nice

[johnschoeman]

Overall this looks great to me, and is an impressive amount of work! I had a question, if you have a moment to answer. Let me know if you want any help finishing the expectations in some of the tests.

[johnschoeman]

👍

[johnschoeman]

I like being able to be explicit about the config here!

[johnschoeman]

This looks great to me. Just to make sure I'm understanding correctly, the reason you are going with jest here as opposed to rspec or minitest is for performance reasons? or is there something else that makes jest preferable?

[kddnewton]

There are a couple of reasons. The #1 is speed - shelling out to ruby -c and rubocop and minitest takes a ton of time. I'd still like to bring that back, but only in an integration test capacity that doesn't need to run for the whole unit test suite. #2 is test coverage. It's really hard to measure test coverage when we're using ruby specs versus just using the stuff built into jest. #3 is the convenience of jest itself (test.only, describe.each, etc.). There's a lot of stuff baked in that makes it pretty nice to work with.

[johnschoeman]

Sounds good to me. Thanks for the explanation.