Add testing in browsers

[denis-sokolov]

As per conversation in #15, added airtap for test running in the browsers.

The diff includes changes from PRs #16, #18, #20, please wait for those to be merged for the diff to be nicer.

Ironically, these tests do not catch the Buffer issue that #15 fixes. During the bundling for testing, airtap uses Browserify, which packages a Buffer polyfill in. I could not find a way to disable that and keep the rest of the tooling working. But unrelated to #15, perhaps this tooling is beneficial for the project.

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[mcollina]

@vweevers do you think we could disable the polifills somehow?

[jsumners]

IMHO, there are too many tangential PRs that are created specifically to support this one PR. I would rather see a single PR that implements the thing you want to implement instead of making decisions on many different ones that are out of context.

[vweevers]

@mcollina Do you want to disable all polyfills (I'm not sure tape will like that) or only buffer? If the latter, then add the following to .airtap.yml:

browserify:
  - ignore: buffer

[denis-sokolov]

@mcollina, @vweevers, I have tried various combinations of exclude and ignore, but only with tape.

@jsumners, a matter of preference, I suppose. A lot of the other PRs are worthy additions with or without this PR. I understand we all have different workflows, so I am sorry for the inconvenience.

[jsumners]

A lot of the other PRs are worthy additions with or without this PR.

Changing the test tool is seemingly only necessary if this PR is to be accepted. Therefore, it doesn't bring value without this PR being accepted. Same for #15.

[denis-sokolov]

@jsumners, I apologize, I do not see value in discussing the merits of individuals pull requests and our individual preferences for workflows. If you find this discussion crucial, you are welcome to close all my pull requests and tell me to get lost. If you are not interested in that, let’s focus on the proposed changes and their integration.

[denis-sokolov]

The summary of the tap vs tape conversation:

• migrating to tape is a relatively easy way to support this PR;
• using tap with airtap seems to require additional efforts;
• choosing another test runner or browser runner requires additional efforts;
• it seems nobody has yet expressed strong objections for the move to tape.

@RafaelGSS, @Eomm, adding you here after the conversation in #16 was moved here.

[denis-sokolov]

@kibertoad, @Eomm, the PR is now ready for another round of review at your convenience.

[RafaelGSS]

LGTM.

[kibertoad]

@denis-sokolov Btw, why is this not failing on browsers despite not including #15?
edit: nvm, you explained it: "During the bundling for testing, airtap uses Browserify, which packages a Buffer polyfill in"

[kibertoad]

What's the benefit of this change if it doesn't reproduce actual behaviour of browsers, though?
Wonder if something like karma works in a way that is closer to the real world browsers.

[denis-sokolov]

It’s unlucky it does not catch the Buffer-related issue in the browser, but it may still catch some other behavior differences some time. If you decide the maintenance burden of airtap is not worth that minor benefit, it makes perfect sense to reject this PR, I won’t take it personally. :-)

It’s likely there is testing tooling that allows us to do better testing in the browser. Unfortunately, we’ve uncovered the Buffer issue in airtap only after implementing this PR. Right now there is not enough incentive to start over with a new tool. ¯\_(ツ)_/¯

[kibertoad]

@denis-sokolov Fair point, also @vweevers promised to look into configuring airtap, so hopefully this can actually be addressed in an optimal way.

[mcollina]

lgtm