I'm improving my tests with RSpec and capybara-webkit, trying to delete all the css and xpath selectors like
find('#edit_user > div:nth-child(7) > div > div > button').click
and I'm looking for the best option to replace them.
I was going to use the css class of the elements but some "pro" capybara tester said this is not the best option.
So my question is: can I use the dataattributes in my tests?If I have an element
<button name="button" type="submit" class="button last" data-test="edit.update">Update/button>
will I be able to do
find('edit.update').click
?
And do you think it is a good idea? If you have more ideas/infos about this topic, feel free to comment!
To locate elements by their data-* attribute, you need to use a CSS-selector or XPath.
For the CSS-selector:
find('button[data-test="edit.update"]').click
For XPath:
find('//button[#data-test="edit.update"]').click
Whether or not it is a good idea really depends on the application. You want to pick something that uniquely identifies the element. If "edit.update" is not going to be unique, it would not be a good choice to use. The class attribute would be fine if the button had a unique class, which "button" and "last" are not likely to be.
The best approach is really to use static id attributes as they should be unique within the page and are less likely to change. The find method also supports locating elements by id, which means you do not have to write CSS-selectors or XPath.
The answer given by Justin Ko is correct, I just wanted to add something slightly more advanced which can help with test readability in some situations. You can add your own "selectors" to Capybara, so if you really wanted to select things by a data-test attribute (not a great idea since you don't really want to be adding attributes just for testing) a lot you could do
Capybara.add_selector(:dt) do
css { |v| "*[data-test=#{v}]" }
end
which would allow
find(:dt, 'edit.update')
this can make tests understandable while also limiting complicated css or path queries to a single place in your test code. You can then define a method such as
def find_by_dt(value)
find(:dt, value)
end
if you prefer the look of find_by_dt...) to find(:dt, ...)
You can also add filters and descriptions to your own selections for more flexibility, better error descriptions, etc - see https://github.com/jnicklas/capybara/blob/master/lib/capybara/selector.rb for the built-in selectors provided by capybara
Related
I am using Capybara to write test in my application, but now i have a situation in which i need to read id of an element within capybara like
myid = page.find("#parentNode").first(".childClass").id
Consider i have the below HTML structure
<div id="parentNode">
<div id="childNode1" class="childClass">1</div>
<div id="childNode2" class="childClass">2</div>
</div>
Please Note : I am not trying to read the content of the child node, but the id. The above shown is for example.
Expected Output : childNode1 (id of first element with class childClass
You are almost near the answer. The only change is instead of calling id as method, you have to call it as attribute as follows
page.find("#parentNode").first(".childClass")[:id]
I would use some xpath instead of css in this case.
Note I am not that skilled in xpathing so I use css first to find parentNode.
find(#parentNode).find(:xpath, div[1]).id
Try that and see if it works.
optionally you can use css in the second find as well and use the class as criteria since it finds the first element anyway.
Got the answer..!!
We can use page.evaluate_script to achieve this. I used the below code
page.evaluate_script('$("#parentNode .childNode").first().attr("id")')
Hope this will help some one :)
is there any way (or plugin) to display editable combobox? I have a set of options, but I would like to give possibility to enter custom value.
I've searched the documentation, and I can't find way to do this. I made workaround with javascript, but I'm looking for more elegant solution.
I'm pretty sure that there simply is no HTML form element that does this, and so Rails can't provide you with a helper. As you said, you can work with JS to create something similar (and there should be JS libraries/plugins already out there), or you could just use a select element and add a text field next to it for new values.
HTML5 specification doesn't define such an element. So you may either continue using JS, either try to use autocomplete feature of an input element (although it is not exactly what you want and doesn't compatible with old browsers).
I often see, touted as one of the big benefits of ASP.NET MVC, the fact that it gets you closer to the actual page markup, as opposed to the pseudomarkup of WebForms.
If that's the case, then why does the HtmlHelper exist? It seems like all this LabelFor, TextBoxFor stuff is just as much pseudomarkup as <asp:Label> and <asp:TextBox> are in WebForms.
What am I missing? Why is there an HtmlHelper class? Do people use it in real life?
Whilst you are right in saying that HtmlHelper functions do abstract away the exact markup rendered, the big advantage of this is that the views are more DRY and you are able to pass in the necessary parameters to the functions in order to customise the HTML generated.
Rather than having to manually type out a full <input /> tag, complete with value=<%= Model.Property %>, Html.TextBoxFor is a more concise way of outputting the same thing. And as with all DRY approaches, if you need to change the HTML for all textboxes in your application (e.g. to output a new attribute) all you need to do is change the HtmlHelper method.
They seem to me a little like simple, lightweight partial views that are just designed to output some consistent HTML given some input.
The point of HTML helpers is to eliminate tedious and repetitive <input> tags.
Unlike server-side controls, HTML helpers emit raw, (fairly-)predictable HTML.
It simplifies the creation of those and allows them to be strongly named. Of course people use this!
I don't quite agree with the answers, and i somehow agree with you.
You can think of the helpers as pre-built custom controls, if you want to have some code generated you can make use of the helpers, if you want a clean approach and get closer to the html then don't.
The important point here is that MVC allows you to get close to the html, but does not limit you to only that.
You can create your own helper that created the markup you wish, and use that instead.
At the end of the day, it comes down to your own preference, and you can choose to or choose not to be closer to the html
So in my Rails application, I'm trying to set up Javascript testing on certain views.
Right now, I'm doing this by having a conditional in each view..
<% if AppConfig['js_testing'] %>
<script>
...
</script>
<% end %>
If I have it on each page, there's a lot of code duplication. Is there a way manage everything from the application layout?
There's a few places you can put this that will help reduce duplication. The main layout is an ideal candidate. Another possibility is a helper method that's a lot easier to introduce.
You could also define a conditional javascript_tag helper method that will only introduce the JavaScript if your trigger is set. Usually this is along the lines of:
def javascript_testing_tag(content)
AppConfig['js_testing'] ? javascript_tag(content) : ''
end
Then it's a pretty straightforward exercise to wrap all your test scripts with that conditional. It will make it easier to refactor things later should the logical trigger for this behavior change.
The optimal implementation depends on what kind of scripting content you're introducing. If it's tied closely to the JavaScript that may be on a particular view, you may be stuck doing this.
An alternative is to simply tag each page and have a testing JavaScript harness that will trigger specific behavior depending on the structure of the document. For example, if there's an element div#user_list you might run testUserList().
It is then trivial to simply not include the testing JavaScript file in non-testing environments.
Is there a specific reason why I should be using the Html.CheckBox, Html.TextBox, etc methods instead of just manually writing the HTML?
<%= Html.TextBox("uri") %>
renders the following HTML
<input type="text" value="" name="uri" id="uri"/>
It guess it saves you a few key strokes but other than that. Is there a specific reason why I should go out of my way to use the HtmlHelpers whenever possible or is it just a preference thing?
Another benefit is that if your ViewData contains a value matching the name of the field it will be populated.
e.g.
ViewData["FirstName"] = "Joe Bloggs";
<%=Html.TextBox("FirstName") %>
will render
<input type="text" value="Joe Bloggs" id="FirstName" />
There are huge benefits:
It has overloaded methods to pre-populate the values (formatted, and safe for HTML) just like the ViewState.
It allows built in support for the Validation features of MVC.
It allows you to override the rendering by providing your own DLL for changing the rendering (a sort of "Controller Adapter" type methodology).
It leads to the idea of building your own "controls" : http://www.singingeels.com/Articles/Building_Custom_ASPNET_MVC_Controls.aspx
One thing is for consistency...I for one always forget the name attribute. Plus, you can extend the functions for your own projects. They're not called helpers for nothing!
The upside to using an abstraction layer is future proofing your code in a pluggable way. Maybe today, you create HTML 4 pages but tomorrow you want to create XHTML pages or XAML or XUL. That's a lot of changes if you just hard code the tags everywhere, especially if you've got hundreds of pages. If everything is calling this library, then all you've got to do is rewrite the library. The downside is that it is usually considered to be slightly less readable by humans. So, it most probably increases the cognitive demand on your maintenance programmers. These advantages and disadvantages really have nothing to do with MVC.
It actually auto populates your textbox based upon first your ViewData.Model.uri and second by ViewData["uri"]. Doing it manually you'd need to do <input value="<%Html.Encode(ViewData.Model.Uri"%>" />
I haven't been doing MVC too long, but I've already written some extension methods to generate menu tabs based on Html.ActionLink. It allows me to be consistent with my usage and, if I decide to change how my CSS menus work, only modify a single method to output the new tab format.
The other use that I have made of them is in conditional output using ViewData to supply values to the controls.