New actions proposal

[balamaci]

Hi, Does it make sense to be able to process some different "actions" like for example { action : "clickelement" id:'settings-lnk' }

Reason: I'd like instead of re-recording to create a slightly different test cases to just be able to tweak an existent record.json file and it's just simple to reference the elements instead of position.

Also for responsivenes testing for different browsers sizes by not referencing the position(that the elements might change) you'd not need to rerecord.

[chenglou]

Hey! The screenSize key in your Huxleyfile changes the browser size, so you can duplicate the task entry and still run it like you would normally. Check out the README for more info =).

[balamaci]

Yes, but if the application is responsive, it might also change the position of the buttons, for ex if screen size is small, a button falls into the next row. So reusing the recording with clicking on screen position is not going to work for this or are you saying something else?

[chenglou]

Yeah Im saying something else, for your Huxleyfile:

[
  {
    "name": "click",
    "url": "http://localhost:8000/component.html"
  },
  {
    "name": "small screen click",
    "screenSize": [500, 300],
    "url": "http://localhost:8000/component.html"
  }
]

It's as simple as that. You record your action twice, and they're naturally treated as independent recordings of course. This solution's also flexible since there might be more changes to your app than button placement, i.e. a whole different navigation menu interaction. Instead of trying to fit two sets of interactions into one recording, it's better to just act as if you're using two different versions of your app (which you are).

[balamaci]

You are right, but I feel that for some of my tests I can skip the recording entirely and just go directly to writing the record.json by "hand" and not care about the actual position of the elements for the click. If I need to later change the position of the buttons I don't have to rerecord. It's like writing a webdriver test with the benefit of comparing in the end the print screens. It seems like the best of both worlds.

I think to implement this would be pretty easy since you're wrapping webdriver, maybe it makes sense to expose some of the guts for some high level tweaks(like clicking on an element by id, value, xpath etc).

[chenglou]

If you insist on testing with position then you actually can: the record.json action for click accepts an (x, y) coordinates for the click location. I made it so that you can directly hack it.

It's not that the implementation of the feature is hard; it's actually one step easier. But if we start targeting elements using selectors then we're back to using selenium js api, except instead of actual commands, you're writing a json.

If I need to later change the position of the buttons I don't have to rerecord

Woah eh, I think you misunderstood this: you can run hud --update without doing a rerecording. For a specific component, you only ever do hux --record once. I'll open an issue on this because the README might be unclear.

[balamaci]

1. "If you insist on testing with position then you actually can: the record.json action for click accepts an (x, y) coordinates for the click location. I made it so that you can directly hack it."

I'm trying to get away for being position dependent. So I'm trying the opposite I don't want to care that an element changed position - That's why I'm trying to select by id components.

1. " you can run hux --update without doing a rerecording". Can I? Consider this: If the Link to ajax replace a panel(the json generated from the recording says "click(30,30)") and I've decided to change the layout to move the button at page bottom, if I run just the update it will not click the button(it will try to click 30,30 which is a textfield now and update the printscreens, so running hux --update will not fix this, only a rerecording will that will generate a new json with click(100, 800)
2. "except instead of actual commands, you're writing a json." I like adding/tweaking the pause times in the json files, I think I could be able to create some json files without working with the browser.

Sorry for not getting my intentions more clear. PS: That readme issue, I don't know I still feel I got the workings ok from it. hux --update just updates the reference printscreens, but it does not update the record.json file.

[chenglou]

Ah sorry, never mind about the update flag then, that was a misunderstanding.

About being position dependent: you're right, currently it is so. The goal, though, is for the library to be usable without touching record.json; and using selectors defeats the purpose. Right now we have designers who depend on this, and we don't want to commit to adding selectors-specific features unless we're really cornered.

If you want to know the details, we're using Facebook's React, which totally kills the need for ids, classes and selectors for js-related manipulations. This is where Huxley shines: no matter what the DOM library or structure is, it seizes the testing at the very end point, which is all that matters.

I think there's a similar issue in the original Huxley repo; I'll keep an eye on this and temporarily close this one. I'll give you the exact lines to make this happen though:

• https://github.com/chenglou/node-huxley/blob/master/source/bigBrother.js#L17
• https://github.com/chenglou/node-huxley/blob/master/source/playback.js#L63

Thanks a lot for the feedback!