Suggestions about chai-webdriverio

[marcodejongh]

@christian-bromann I hate coffeescript with a passion, but I thought it would be a "easy fix".
I'm gonna re-do this module in ES6 only using the chai-webdriver module as inspiration.

None of the assertions would need a DOM flag perse, it only results in a more explicit API, but I think in most cases it makes sense to get rid of it, but in others it doesn't. For example if you where to implement exist

expect('.some-selector').to.exist;

expect('invalidselector').to.exist;

It becomes hard to tell what exactly you want to assert, because if you check if something is a css selector the 2nd example will return true, because when overriding existing assertions you call the super if it doesn't match your current. But then again the other way of looking at it is that if you add the chai-webdriverio assertion helpers you're going to be using chai in a UI testing way so it might be okay to change some existing behaviour of chai.

I just have 1 question for you, how would you recommend finding out if the current mode is promise or sync based? I'd rather not just look for .then, so if there's another way please let me know

[marcodejongh]

@christian-bromann Finished the rewrite, I've only implemented the methods I need right now but everything is ES6 and properly unit tested.

I think I'll implement promise based use later when I have the time. I'm thinking of wrapping the client with a fibers layer so it behaves synchronous in my tests. What do you think? I haven't looked at the wdio cli tool yet but I'd assume that's how it works

[christian-bromann]

promise or sync based?

it is sync based when there is a global browser object that is an instance of WebdriverIO and the following is true: `.options.sync.

wrapping the client with a fibers layer

I am not sure if this is possible. To do so you need to also overwrite the it method or at least something that you can give a promise (a future object) and the execution stops until that is resolved.

In general having that plugin for sync mode only is absolutely fine. Remember that for async you can still transfer promises to chai and use chai-promise to write code like:

    it('should contain a certain text after clicking', function() {
        return client
            .click('button=Send')
            .isVisible('#status_message').should.eventually.be.true
            .getText('#status_message').should.eventually.be.equal('Message sent!');
    });

which is basically the same.

[jedwards1211]

@christian-bromann I'm confused about the chai-as-promised chains in your example. You're chaining them onto a webdriverio client object, right? I don't see how they would work without being chained onto expect.

I hate node-fibers with a passion, so I may at some point work on my own chai plugin for doing async webdriverio assertions.

[christian-bromann]

@jedwards1211 I would recommend to use expect-webdriverio from now on. It also supports async command execution.

[jedwards1211]

sigh, I'm using chai though, not expect

[jedwards1211]

I often end up wishing a lot of assertion utilities like this were standlone libs instead of plugins for the disparate assertion frameworks out there

[jedwards1211]

Okay I made an async fork of this: https://github.com/jcoreio/chai-webdriverio-async

[christian-bromann]

so there is no chance to incorporate it into this library?

[jedwards1211]

it's certainly possible, I just have so much work to get done ATM I didn't want to make a PR and wait for it to get approved. I found out recently that Chai/Mocha's not as popular as Jest/Expect these days, and this package doesn't have many stars...anyone who needs async (which is more of a minority I assume) can now use my fork anyway, so I just didn't think it was the best use of my time making a PR to this package