Unit tests

[dselman]

We need unit tests for the JSON <-> MD conversion

[jeromesimeon]

Any thought about how those would be written? Using jest or more traditional mocha-style tests?

[jeromesimeon]

Roundtrip tests would be useful. To answer my own question, jest seems like a fine choice. Here is a small example:

test('can roundtrip basic text', () => {
  const markdownText = 'This is some text.';
  const value = fromMarkdown.convert(markdownText);
  const markdownRound = toMarkdown.convert(value);
  expect(markdownRound).toEqual(markdownText);
});

Note that even that first test fails round-tripping:

  ● can roundtrip basic text

    expect(received).toEqual(expected) // deep equality

    Expected: "This is some text."
    Received: "This is some text.

    "

This may tie into some of the whitespace issues mentioned in accordproject/cicero-ui#43

[jolanglinais]

Hacktoberfest:

This issue can provide for multiple pull requests.

[codingdefined]

@irmerk I would like to work on it. Does the tests should be only on the JSON <-> MD conversion? What all scenarios should we consider for the testing, like all the buttons in the toolbar?

[jolanglinais]

@codingdefined this would be great to pick up! Just keep aware of the changes we're making in PRs #114 and #117 over the next few days.

We're using the markdown-transform now, so the conversions are described more in that README. I think the more tests the better, essentially. Testing buttons, testing copy-pasting, testing adding a clause template... If you'd use the editor in X way, we should test X.

[jolanglinais]

@codingdefined what is the status on this issue?

[codingdefined]

@irmerk Created the pull request for the same.

[jolanglinais]

As mentioned in #134, this issue can provide for many PRs, so I will open this up.

[jolanglinais]

Please note the conversation in markdown-transform #117 for testing this repo.

[jolanglinais]

Closing for accordproject/web-components#14