Tests for Bliss.shy

[renoirb]

How should we test Bliss in shy mode?

A few questions came up to mind when I started looking how we test shy mode.

• Should we review how Bliss init itself?
• Should we allow multiple instances and tell which document to init onto?
• Where should it run?

Expexted outcome

Test all shy mode features and ensure it behaves as documented.

[vlazar]

When I needed to test something similar on another project, I created 2 separate Karma configs. But then I lost ability to run Karma tests in continuous mode. So I didn't like that solution.

Then of course Require.js can be used with Karma too.

I feel this is a somewhat related feature opened on Karma that covers many use cases like grouping test files. Unfortunately it looks like it wouldn't be implemented, because spec is non trivial for this feature (so meta):

This feature's spec is non trivial, therefore the implementation was not as clean and I would hope, and the benefits were not convincing enough to go ahead with it, so we scrapped this plan.

There is discussion Should we make Bliss a dependency? for Awesomplete. I hope one day (ES6) modules would be used in Bliss source. Would be easier to do many things.

[LeaVerou]

This is a serious problem that we do need to solve somehow. Another serious problem is testing in various browsers, to make sure that we're not depending on some kind of browser bug. No suggestions at the moment, about either of these issues :(

[vlazar]

The Browserstack and SauceLabs were mentioned in #82 to help with testing in various browsers.

[renoirb]

I guess I've been "lucky" to pick the hardest featureset to write tests for for my first contribution.

This may sound obvious but I'll ask anyway. Is there a in-browser test runner that we could use with the same tests? With that, we could continue develop features and test them while other works on making it a module.

[LeaVerou]

Is there a in-browser test runner that we could use with the same tests? With that, we could continue develop features and test them while other works on making it a module.

I wish. We've discussed this in #71 and #82 but without much avail.

[renoirb]

There's Jasmine. But the syntax isn't the same :( ... but we may have something for us with karma-jasmine though. (after checks) but we have it already.

[vlazar]

Is there a in-browser test runner that we could use with the same tests?

@renoirb I'm not quite sure what do you mean by this. Karma already runs tests in Chrome. It doesn't matter whether it's mocha or Jasmine tests.

Do you mean using the same set of tests for in-browser and in-node tests? But then why would Bliss need to be tested in node?

The discussion in #71 about having HTML reporter to see results and re-run tests in browser is weird. Why not use console? There are some plugins to see test results in HTML though and the page can be reloaded to re-run them. Also Karma has continuous mode. When you run it with karma start it watches for file changes and re-runs tests automatically. Very convenient mode for fast feedback.

[dperrymorrow]

the tests are actually written in Mocha, #1 Jasmine in the NPM dependancies is just leftover. I can prune that, or anyone can pull request that cleanup.

I think that running in the console for development is ideal, and then having integration with something like SauceLabs for testing cross browser on commit like we are currently doing with Travis would be best.
https://docs.travis-ci.com/user/sauce-connect/

To run all the browsers locally would take quite a bit of setup. I have done this before and dealing with VirtualBox for the IE browsers is less than convenient.

[LeaVerou]

Agree @dperrymorrow!

[renoirb]

Thanks for the clarification @dperrymorrow, I wasn't sure if it was needed or not.

I was confused on how Mocha runs tests @vlazar but now I get it, it runs in browsers you connect the websocket servers to. This is new stuff for me. But it all makes sense now.

[franciscop]

For the cross-browser testing, I am currently testing Umbrella JS (which is really similar to Bliss) in the following way:

• Grunt: a grunt watch compiles everything and tests it with Phantom JS (webkit) when needed.
• Circle CI: in a similar way to grunt, but when uploaded to github. Also there's a badge that shows in the repository.
• Website: The website umbrellajs.com/tests has the same tests as grunt but they run in the browser; so I check in Firefox/others or open http://browserstack.com/ and check whether they pass or not in IE11. Lower IE are for348€/year which I'm not going to pay for my hobby project, but you might. Or just open a windows xp/7 VirtualBox instance.