Kind of a strange one, but in my views I have a tick (✔) and a cross (×) used as links (in lieu of images). Is there any way of finding these elements and testing them using RSpec and Capybara-webkit, or should I try and target say the title attribute instead and ignore this route?
My test in question looks like this:
context "casting a vote", js: true do
before do
sign_in user
click_link '✔'
sleep 0.2
end
it { should have_content("Vote cast!") }
end
The failure message I get is (predictably):
Failure/Error: click_link "raw('✔')"
Capybara::ElementNotFound:
Unable to find link "raw('✔')"
Thanks in advance for your help.
Capybara doesn't see the HTML, it runs thru the DOM, which then sees the actual values those things encode. You must send the raw code as a UTF-{8,16} string containing the code point itself.
Most languages would present an HTML '✔' as "\u10004", so try that.
Related
I am facing a behavior that I really don't understand.
If you go on the webpage: https://www.edel-optics.fr/Lunettes-de-soleil.html#ful_iPageNumber=1 and inspect the code you will realize that it's the same html content as on https://www.edel-optics.fr/Lunettes-de-soleil.html#ful_iPageNumber=7
=> to test it, try to search "ERIKA - 710/T5" on both source codes and you will find it (but you should only find on the ful_iPageNumber=1).
Why is it behaving like this ?
Secondary question: how to I get the real content of https://www.edel-optics.fr/Lunettes-de-soleil.html#ful_iPageNumber=7 ?
Thank you for your help
John
Problem
You have explained that when you perform a search, you get the same results as with your pagination (page 1)
Issue
You are not getting the value your searching for placed into the URL
https://www.edel-optics.fr/Recherche.html?time=1519871844737#query=
the #query is = to nothing
You would be needing something like:
https://www.edel-optics.fr/Recherche.html?time=1519871844737#query=ERIKA%20-%20710/T5
Without seing your code its hard to say where the issue lays. it could well be that the search box is not inside the Form or it could be that the submit button is on another form to the search box, or maybe an issue with backend scripts not grabbing the get values as a result of case differences in the value name.
Without seing your script its hard to diagnose
Ok I found a solution to solve this strange problem, replace the # in the URL with a ? and you will have the actual html content (corresponding to the display)...
I'm developing an ASP code that read a external websites and parse it via HTMLDocument interface Object ( "HTMLFILE" Object) to navigate contents via DOM structure. But there are some pages that throw an error :
'htmlfile error 80070057 Invalid Argument.'
After doing a lot of research, I've discovered that there are some HTML tags that, i don't know why, are not rendered or managed correctly by HTMLFILE object giving me that error.
Because ASP is too old and there isn't much content available today to be probing, I'm convinced that I have to parse it before send to HTMLFILE Object, and the best way that I have figured is to do via RegEx.
But I'm facing some problems (and because i don't have much practice).
I have to successfully locate HTML Tag Blocks that 'HTMLFILE' do not accept to be able to remove them.
For Example:
<head>
<script> ....... </script>
<style> ....... </style>
</head>
<body>
<iframe> ........ </iframe>
<div> ..... </div>
<table>.....</table>
I have to match full script block, style and iframe, leaving the rest of document intact.
From last days i've doing some research and have almost done it:
<(?:script|embed|object|frameset|frame|iframe|meta|style).+(.|\s)*?>$
I've tried to match single line tag (for example '<BR>') but I'm totally confused now and there are some inconsistencies on it, for example, some of lines that close some tags are improperly selected.
I Know that the best way is discover why HTMLFILE is throwing me on error, but there is no more information on error to debug it.
Thank for all the time and patience.
Here is the regex candidate:
<(script|meta|style|embed|object|frameset|frame|iframe)[\s\S]*?<\/(script|meta|style|embed|object|frameset|frame|iframe)>
DEMO with explanation
EDIT
Update with lazy match for [\s\S]*?
Regex is not best tool for that, take a look here, but if you really want, I think in simple cases you can also use one regex for all tags, also nested:
(?=(<([^>]+)>([\s\S]*?)<\/\2>))
DEMO
the 1st groups shows whole captured part, 2nd groups capture just tag, and 3rd group capture content of tag. It doesn't actually match text, only capture some fragments. However you probably can get start/end index of match, and use in as you want.
Still I think you should reconsider using regex, however suntex used above is quite useful, so it is worth to know how to use it.
I'm working on a Play application and need to generate links in a mixed Scala-HTML view that call controller actions. I found this question from a couple years ago that's similar to my situation, but the provided answers don't work for me.
The elements are generated in a loop so I can't manually insert the argument to the controller action, but nothing I've tried has worked. This is the line I have now:
ID: #{var fhirID = <processing for ID>; <a href='#routes.Users.fhirUserDetails(fhirID)'>fhirID</a>}
The accepted answer to the question I linked earlier effectively uses this structure too:
<a href='#routes.Application.show("some")'>My link with some string</a>
My issue here is twofold:
1) How can I have the variable fhirID passed to the controller action? My generated link simply has the text "fhirID" instead of what's generated by the first part of the statement.
2) Is the #routes.Users syntax correct? When I click the generated link, it literally attempts to render a page at /myapp/#routes.Users.fhirUserDetails(fhirID)
I realize I'm probably missing something very basic here- thanks for any advice!
The problem seems to be not the #routes syntax (which you have completely correct) but rather a case of the Twirl engine not seeing where code ends and HTML begins (or something like that anyway...)
The line you've included, which has both a var and a semicolon, made me suspect this, and I've been able to reproduce the problem when I use that style.
My recommendation is to use the #defining helper rather than var to get a scoped variable for use in your links, as follows:
ID: #defining(<processing for ID>) { fhirID =>
<a href='#routes.Users.fhirUserDetails(fhirID)'>fhirID</a>
}
You can nest #defining blocks as deeply as you like if necessary, although it's probably better to make a call out to a reusable block if there's a lot of logic. I think this style makes for more-readable templates and also somehow looks more like "real Scala" :-)
A W3C-validated HTML 5 web page contains this working, simple button inside a login form.
<input data-disable-with="Signing in, please wait…"
name="commit" type="submit" value="Sign in" />
I'm writing a largely pointless test :-) in a Rails 3.2.17 application that's just to get the hang of Capybara and I've already got completely stuck Googling, reading documentation and reading source code to the test framework, with no joy - attempting to find this button by its name (i.e. "commit") fails.
click_button("commit")
find_button("commit")
Both result in Capybara::ElementNotFound: Unable to find button "commit". If I use the visible button text of Sign in then the element is found, i.e. these:
click_button("Sign in")
find_button("Sign in")
...both work fine, so it would appear that the XML parser isn't having any trouble finding the element.
Documentation for click_button says that the locator works on "id, text or value", with "text" being meaningless for an input element like this (the visible text is taken from the value attribute), but relevant perhaps for button elements. So, we might expect that to fail, though if we view the code via the documentation, find that it calls down to find in the same way as find_button. Yet find_button is documented differently; it says it locates by "id, name or value". So sadly, we know from this that the documentation is broken because it says two different things for what turns out to be an identical call at the back end.
Either way, the element isn't found by name, and that means the lower level find call isn't searching name attributes as far as I can see. This means Capybara (2.2.1, on Nokogiri 1.6.1) is rather broken in that respect. How come nobody has noticed? I've Googled for ages and it doesn't seem to come up. I seem to be rather missing the point :-)
Why don't I just search for the English text in the button, you might ask? Because of internationalisation. This old, Rails 1 -> 2 -> 3 upgraded app has some I18n parts and other static text parts. I don't want to be forced to put I18n into any view that Capybara tests, just so I can have the test use I18n.t() to ensure a match despite different languages or locale file updates. Likewise, it would clearly be very stupid in 2014 to write hard-coded English strings into my tests.
That's why we have names and IDs and such... The unique (in theory!) identifiers that are machine-read, not human-read.
I could hack up something that CSS-selected by "type=submit" but seriously, why isn't Capybara searching the name attribute when its documentation says it does, and why does the documentation disagree on what attributes are searched on two methods that call down to exactly the same back-end implementation with exactly the same parameters?
TIA :)
It turns out the docs are misleading for both calls, as neither look at the attributes listed. It's also clearly very confusing what exactly a "button" means, since a couple of people herein seemed to think it literally only meant an HTML button element but that's not the case.
If you view the source for the documentation of, say, click_button:
https://github.com/jnicklas/capybara/blob/a94dfbc4d07dcfe53bbea334f7f47f584737a0c0/lib/capybara/node/actions.rb#L36
...you will see that this just calls (as I've mentioned elsewhere) to find with a type of :button, which in turn passes through to Capybara's Query engine which, in turn, ends up just using the standard internal selection mechanism to find things. It's quite elegant; in the same way that an external client can add their own custom selectors to making finding things more convenient:
http://rubydoc.info/github/jnicklas/capybara/master/Capybara#add_selector-class_method
...so Capybara adds its own selectors internally, including, importantly, :button:
https://github.com/jnicklas/capybara/blob/a94dfbc4d07dcfe53bbea334f7f47f584737a0c0/lib/capybara/selector.rb#L133
It's not done by any special case magic, just some predefined custom selectors. Thus, if you've been wondering what custom selectors are available from the get-go in Capybara, that's the file to read (it's probably buried in the docs too but I've not found the list myself yet).
Here, we see that the button code is actually calling XPath::HTML.button, which is a different chunk of code in a different repository, with this documentation:
http://rdoc.info/github/jnicklas/xpath/XPath/HTML#button-instance_method
...which is at the time of writing slightly out of date with respect to the code, since the code shows quite a lot more stuff being recognised, including input types of reset and button (i.e. <input type="button"...> rather than <button...>...</button>, though the latter is also included of course).
https://github.com/jnicklas/xpath/blob/59badfa50d645ac64c70fc6a0c2f7fe826999a1f/lib/xpath/html.rb#L22
We can also see in this code that the finder method really only finds by id, value and title - i.e. not by "text" and not by name either.
So assuming XPath is behaving as intended, though it's not clear from docs, we can see that Capybara isn't documenting itself correctly but probably ought to make the link down to XPath APIs for more information, to avoid the current duplication of information and the problems this can cause for both maintainers and API clients.
In the mean time, I've filed this issue:
https://github.com/jnicklas/capybara/issues/1267
You can also use css selectors which are default capybara locators. People say they are faster.
find('[name=commit]').click
Capybara do not look at name attribute in it's finders :(
You can use xpath selector if you want
find(:xpath, "//input[contains(#name, 'commit')]").click()
If anyone wants it is possible to add (quite easily) find by name selector. In order to do so:
Add following code to test/test_helper.rb (for minitest)
Capybara.add_selector(:name) do
xpath { |name| XPath.descendant[XPath.attr(:name).contains(name)] }
end
Use it
Now in your tests you can use following selector:
find(:name, 'part_of_the_name_attribute')
It will find every element which name attribute contains searched value.
Example
find(:name, 'user')
This will find elements (element could be of any type):
<select name='user_name'>
<input name='name_of_user'>
<textarea name='some_user_info'>
You can use this selector to find a button on a page with RSpec and Capybara:
expect(page).to have_selector(:link_or_button, "Button text")
Check your gem depencies. RSpec 3 or higher works with gem 'rspec-rails', '~> 3.7.1' then capybara version must be gem 'capybara', '~>2.18.0' and poltergeist should be gem 'poltergeist', '~>1.17.0'.
I have what I feel is a very simple question about Umbraco, but one that has as of yet no apparent answer.
I have a razor template, standard stuff, with # displaying variables and some inline C# code.
At one point in the template I use:
#Umbraco.RenderMacro("myCustomMacro");
no problems there, everything works as expected.
Now, this macro is inserted on every page (it's in the master template) but I have a page property that allows the content authors to turn it on and off via a check box in the page properties, again so far so good everything works perfectly.
However I now find that for a certain "document type" this component MUST be displayed, so I've been trying to find a way to perform that check.
Now in my mind, this should be as simple as doing something like this:
#{
if(CurrentPage.documentType == "someDocTypeAliasHere")
{
//Render the macro
}
else
{
// Render the macro only if the tick box is checked
}
}
as I say, this is (or I believe it should be anyway) a very simple operation, but one that so far does not seem to have a result.
What Have I tried so far?
Well apart from reading every page on our-umbraco that mentions anything to do with razor & the #CurrentPage variable, Iv'e been through the razor properties cheat sheet, and tried what would appear to be the most common properties including (In no specific order):
#CurrentPage.NodeTypeAlias
#CurrentPage.NodeType
#CurrentPage.ContentType
#CurrentPage.DocumentType
and various letter case combinations of those, plus some others that looked like they might fit the bill.
Consistently the properties either don't exist or are empty so have no useable information in them to help determine the result.
So now after a couple of days of going round in circles, and not getting anywhere I find myself here..
(Please note: this is not a search the XSLT question, or iterate a child collection or anything like that, so any requests to post XSLT, Macros, Page templates or anything like that will be refused, all I need to do is find a way to determine the Document Type of the current page being rendered.)
Cheers
Shawty
PS: Forgot to mention, I'm using
umbraco v 4.11.8 (Assembly version: 1.0.4869.17899)
Just in case anyone asks.
In Umbraco 7 use currentPageNode.DocumentTypeAlias
In Umbraco 7.1 I use: #if (#CurrentPage.DocumentTypeAlias == "NewsItem")
think you do actually need to create a node each time when you are on the page to access the pages properties like nodetypealias and stuff, try this i have the same kind of functionality on my site, http://rdmonline.co.uk/ but in the side menu where depending on the page/section it shows a diff menu links.
#{
var currentPageID = Model.Id;
var currentPageNode = Library.NodeById(currentPageID);
if (currentPageNode.NodeTypeAlias == "someDocTypeAliasHere")
{
//Render the macro
}
else
{
// Render the macro only if the tick box is checked
}
}
Let me know if this works for you.
This is a bit unrelated to this post, but searching Google brought me to this post, so I thought I'd share in case anoyne else is dealing with this issue: In Umbraco 7, to get all content in the site for a specific type:
var articles = CurrentPage.AncestorOrSelf(1).Descendants()
.Where("DocumentTypeAlias == \"BlogPost\"").OrderBy("CreateDate desc");
If your razor view inherits from Umbraco.Web.Mvc.UmbracoViewPage, you could also use UmbracoHelper:
#if (UmbracoHelper.AssignedContentItem.DocumentTypeAlias.Equals("NewsItem")) { ... }
Querying for a specific DocumentType is also easy:
UmbracoHelper.AssignedContentItem.Descendants("NewsItem")
This code will recursively return the list of IPublishedContent nodes.
If you wish to use this list with your specific DocumentType information, these items would have to be mapped to the specific type. Other than that, IPublishedContent gives you the basic information for the nodes.
I've later saw that you have been using an older version of Umbraco. :)
This implementation is only for v7.