Webdriver Usage

[jhnns]

When I was reading your code, I saw that you're barely using any typical webdriver methods (like sendKeys, click). You seem to prefer to execute scripts directly. Is this intended and on a special purpose? Or just your preferred style?

I thought that the webdriver executes the given commands natively in the browser, which means that it actually works exactly like if the user interacted directly with the browser. Imho this is more accurate since JavaScript emulation is not exactly the same like user interaction (concerning dom events for instance). Or am I wrong and the Webdriver is just executing JavaScripts as well?

However, it seems like the Webdriver isn't supporting all necessary interactions like scrolling with the mouse wheel. I met this problem because I need to test mouse wheel scrolling on a specific element (which neither huxley nor the webdriver supports).

[chenglou]

(Code's kinda messy, I'm refactoring bits out, sorry). I do use these methods though: https://github.com/chenglou/node-huxley/blob/master/source/playback/index.js#L100-L124 Selenium's click isn't perfect so I added some small stuff on top of it. Key might also change in the future. I really dislike catching bugs because of key events (https://github.com/chenglou/node-huxley/blob/master/source/browser/actionsTracker.js). And of course it doesn't reproduce copy/paste, etc. The easy way would be to keep track of the input value at each keystroke, but that kinda makes record.json harder to hack for some people.

During the refactor, I was thinking of pulling this tracking script out into its own lib that people can reuse and contribute to. Think of it as an analytics library that actively records actions. Back here in huxley I can just filter out what I don't need. If you know any similar project please do tell; I don't wanna reinvent the wheel.

Scrolling nested items: #53 One thing I need to take care of is to disable the scrollbar for every single item, or else Mac's fading scrollbar runs into the same problem as screenshot-ing during animation. I ran into a bug trying to hide all the scrollbars; I'll try again another time.

The problem of scrolling nested items is hard. Because so far the record/replay have the nice property of not needing to be re-done when your DOM structure changes (I should totally promote this more). If I want to scroll a nested item, I'd have to keep track of the item, and all bets would be off if you refactor your structure in the future. I'm not sure how to solve this yet. I guess this makes your site more mobile ready since it doesn't use nested scrolling (bad excuse lol).

Edit: keep them feedback coming! =)

[jhnns]

Yesterday I tested selenium's firefox plugin Selenium IDE which tracks user interactions. I somehow like the plugin approach since the setup is fairly easy which means that recording and replaying can also be done by non-programmers. But I really disliked that they're exporting ready-to-use code which means that you need to write and install a plugin for every language out there.

That's why I thought about creating a specification proposal for some sort of user interaction protocol inspired by your records.json. It would be nice to have this standard since different tools concerned with recording and replaying would just need to be compatible to a records.json. It'd be almost the same like the JsonWireProtocol, just serialized.

I think separating recording and replaying is a reasonable thing. You still can provide a ready-to-use binary which integrate these separate libs. Another advantage of this approach is that it's up to you if you want to setup a selenium grid or just want to emulate the record within the browser. It'd bring way more flexibility for different testing use-cases.

Regarding scrollbars: We had the same issue. Since we're also developing on different OS we needed to agree on a common reference OS. We decided to use a headless Ubuntu with a headless firefox which renders beautiful Windows 95-style scrollbars :grin:. At least they're not fading and anything.

To be honest: I don't get the point regarding DOM structure changes. Huxley is typically recording the coordinates of a click which might change if I change the DOM structure.

[chenglou]

Do you know if there's a way to use Selenium IDE without installing a plugin?

Regarding record.json: yeah, that's what I'm thinking. Except record.json will probably stay Huxley-specific. I want to expose the raw json result from actionTracker.js so that if you don't want some pieces of info, you can filter it out. It's less opinionated and record.json comes from processing that raw json. I'm basically reimplementing part of Selenium IDE but without bundling all the plugins =/.

For DOM structures: I was more talking about the decision for not using selectors to target items to click/send key presses to. Because or else you'd have to update your tests' record.json each time you decide to change the class name of a tag, or wrap it in another tag, etc., in which case huxley wouldn't be much better than the traditional tedious way of unit testing DOM. If the DOM structure changes because you made a visual change, then yes, you'd have to re-record the new look anyways so it's a non-problem.

[jhnns]

I've opened the xul-file of the Selenium IDE plugin (it's just an ordinary zip-file), but I can't find the record-code... :(

I don't think that the record.json needs to be Huxley-specific. The current record.json can be consumed by any program since it only contains instructions on the webdriver communication.

[jhnns]

Oh and yes, coordinates are better than css selectors since css selectors are likely to change more often.

[chenglou]

I'm slowing modularizing the codebase, so here: https://github.com/chenglou/node-huxley/tree/master/source/playback Now it's clearer how the playback simulation works. Hope that helps.

[jhnns]

Yep, that's much better! :+1: