Re:Why Recorded/Playback Tests in Selenium Break
by moogly on Tuesday April 18, 2017 @08:28AM
(#14138248)
Not necessarily. For instance, in many (most?) SPAs, forms are just a... formality. Something to get your Bootstrap-based (or equivalent) CSS to look proper, but the actual form data is pre-processed in JavaScript and sent via an XMLHttpRequest.
Re:Why Recorded/Playback Tests in Selenium Break
by onion2k on Tuesday April 18, 2017 @09:44AM
(#14138721)
Even if you're not using the name in the form data you're still giving it meaning and importance by using it in a locator - you're saying "find the specific element in the page that has the name 'FullName'". If you don't actually care what the name is then you should use something else, like an ID attribute.
Re:Why Recorded/Playback Tests in Selenium Break
by moogly on Tuesday April 18, 2017 @10:45AM
(#14139205)
Sure, I don't necessarily disagree with the sentiment you're expressing, I'm just saying that today, HTML forms aren't as tied to the backend as they used to be.
Though personally I wouldn't want to have to start adding ids and names to things in the markup just for Selenium to find them.
This first example is weird. That change has a pretty big impact on the way the form works; browsers serialize forms using the name attribute so that change means the form data that's sent when the form is submitted is going to be different to what it was before. You'd get FullName=<value> in the form encoded data from the first input and Name=<value> in the second. I would expect a change like that to break a test.
If you don't care what the name is then don't use it in your UI tests. For example, use an ID instead. Using <input name=“FullName” id="nameinput"/> you could locate the element using by.id('nameinput'), and then you could change the name <input name=“Name” id="nameinput"/> and your tests would carry on working.