Is there a way to get some help from RubyMine's code completion when using Capybara in Cucumber's step definitions? I'm new to Capybara, so not having to check the reference site all the time would be really helpful.
The best I can get at the moment is by explicitly calling Session.new, something like:
session = Capybara::Session.new(:rack_test, my_app)
This way Ctrl+Space after session. shows me methods from Capybara::Session (only) so at least I know it's somehow reachable. But that's not how I really use Capybara in my step definitions. I thought that helping the type inference engine by manually annotating page could do the trick, but I suppose all this DSL magic is too much to handle.
So basically, is it somehow possible to have
page.<Ctrl+Space>
pop up with all the exposed DSL methods? RubyMine API maybe? Or, as an alternative, some other way to bring the reference docs closer (I don't think RubyMine supports external docs in the IDE yet)?
As of RubyMine 8.0.3 the answer is no, RubyMine does not complete Capybara methods following page. in Cucumber step definitions, at least not when Capybara is included in Cucumber via the cucumber-rails gem. I don't see a feature request in the RubyMine issue tracker; someone could add one if they like.
Note that cucumber-rails, at least, includes the Capybara DSL in the Cucumber world, so you don't need to type page. in front of Capybara methods. You can just call visit, fill_in, etc. as self methods. I wouldn't want unnecessary page. in my step definitions just for the sake of RubyMine completion.
Unfortunately, RubyMine also doesn't include Capybara methods in the list of names it completes when you invoke completion in a step definition before you type anything. It does include Capybara methods in the list of names it completes when you invoke completion twice (all names in all available code), but since that list is so long it's only helpful if you already know the method you want already, or at least a correct prefix.
Finally, found a solution.
I am using Cucumber with Capybara and I included all the matchers I wanted to code complete in /features/support/spec/spec_helper.rb. Cucumber auto-loads everything in this file. I bet there are other places you can include these statements if you aren't using cucumber.
# Needed for RubyMine code completion
include Capybara::Node::DocumentMatchers
include Capybara::Node::Matchers
include Capybara::SessionMatchers
include Capybara::RSpecMatchers
include Capybara::RSpecMatcherProxies
For your specific case:
include Capybara::DSL
Then
Related
I want to have an option on the cucumber report to mute/hide scenarios with a given tag from the results and numbers.
We have a bamboo build that runs our karate repository of features and scenarios. At the end it produces nice cucumber html reports. On the "overview-features.html" I would like to have an option added to the top right, which includes "Features", "Tags", "Steps" and "Failures", that says "Excluded Fails" or something like that. That when clicked provides the same exact information that the overview-features.html does, except that any scenario that's tagged with a special tag, for example #bug=abc-12345, is removed from the report and excluded from the numbers.
Why I need this. We have some existing scenarios that fail. They fail due to defects in our own software, that might not get fixed for 6 months to a year. We've tagged them with a specified tag, "#bug=abc-12345". I want them muted/excluded from the cucumber report that's produced at the end of the bamboo build for karate so I can quickly look at the number of passed features/scenarios and see if it's 100% or not. If it is, great that build is good. If not, I need to look into it further as we appear to have some regression. Without these scenarios that are expected to fail, and continue to fail until they're resolved, it is very tedious and time consuming to go through all the individual feature file reports and look at the failing scenarios and then look into why. I don't want them removed completely as when they start to pass I need to know so I can go back and remove the tag from the scenario.
Any ideas on how to accomplish this?
Karate 1.0 has overhauled the reporting system with the following key changes.
after the Runner completes you can massage the results and even re-try some tests
you can inject a custom HTML report renderer
This will require you to get into the details (some of this is not documented yet) and write some Java code. If that is not an option, you have to consider that what you are asking for is not supported by Karate.
If you are willing to go down that path, here are the links you need to get started.
a) Example of how to "post process" result-data before rendering a report: RetryTest.java and also see https://stackoverflow.com/a/67971681/143475
b) The code responsible for "pluggable" reports, where you can implement a new SuiteReports in theory. And in the Runner, there is a suiteReports() method you can call to provide your implementation.
Also note that there is an experimental "doc" keyword, by which you can inject custom HTML into a test-report: https://twitter.com/getkarate/status/1338892932691070976
Also see: https://twitter.com/KarateDSL/status/1427638609578967047
I want to have an option on the cucumber report to mute/hide scenarios with a given tag from the results and numbers.
We have a bamboo build that runs our karate repository of features and scenarios. At the end it produces nice cucumber html reports. On the "overview-features.html" I would like to have an option added to the top right, which includes "Features", "Tags", "Steps" and "Failures", that says "Excluded Fails" or something like that. That when clicked provides the same exact information that the overview-features.html does, except that any scenario that's tagged with a special tag, for example #bug=abc-12345, is removed from the report and excluded from the numbers.
Why I need this. We have some existing scenarios that fail. They fail due to defects in our own software, that might not get fixed for 6 months to a year. We've tagged them with a specified tag, "#bug=abc-12345". I want them muted/excluded from the cucumber report that's produced at the end of the bamboo build for karate so I can quickly look at the number of passed features/scenarios and see if it's 100% or not. If it is, great that build is good. If not, I need to look into it further as we appear to have some regression. Without these scenarios that are expected to fail, and continue to fail until they're resolved, it is very tedious and time consuming to go through all the individual feature file reports and look at the failing scenarios and then look into why. I don't want them removed completely as when they start to pass I need to know so I can go back and remove the tag from the scenario.
Any ideas on how to accomplish this?
Karate 1.0 has overhauled the reporting system with the following key changes.
after the Runner completes you can massage the results and even re-try some tests
you can inject a custom HTML report renderer
This will require you to get into the details (some of this is not documented yet) and write some Java code. If that is not an option, you have to consider that what you are asking for is not supported by Karate.
If you are willing to go down that path, here are the links you need to get started.
a) Example of how to "post process" result-data before rendering a report: RetryTest.java and also see https://stackoverflow.com/a/67971681/143475
b) The code responsible for "pluggable" reports, where you can implement a new SuiteReports in theory. And in the Runner, there is a suiteReports() method you can call to provide your implementation.
Also note that there is an experimental "doc" keyword, by which you can inject custom HTML into a test-report: https://twitter.com/getkarate/status/1338892932691070976
Also see: https://twitter.com/KarateDSL/status/1427638609578967047
I am re factoring large sets of tests in SoapUi.
Is there a way to automate creation and renaming of test cases/test steps through Groovy?
Thanks.
Possibly not what you're looking for but I've had some success manually editing the test suite xml using find and replace in a text editor. You need to be careful and make sure to back up a copy.
You can run Groovy code within SoapUI using SoapUI Groovy Console plugin. This way, you can change any property you want programmatically (within API constraints of course).
As for technical details on how to solve your actual problem, I can only refer you to this blog post and SoapUI's javadoc. Based on the blog post, you need to figure out what's given to you, and based on the API, you need to figure out how to achieve what you need.
In my case, I started with my project being bound as a project variable, and moved on from there.
There is really not so much information in the question about what you really need to achieve, but given the little you provided, one way to go would be to directly modify the soapUI project XML file. I have done this with some success in the past. The last I used soapUI, it UI did not come with massive refactoring functionality.
As I have asked questions in this form - thanks for your many helpful answers - i have found many really neat things that one can do using ExtLibUtil.???? however, other than a bit here and a bit there I have not found anything that gives a listing on the various functions. I one post I read that it is all in the source of the extension Library, and it might be if you really understand where in the source to look. Sure would appreciate a pointer and starting point.
I've been unable to find a JavaDoc for it. The library slipped passed us when we wrote the book - certainly I was not as au fait with Java to be aware of it and all the strength within it. So the best option currently is to look at the source code in Eclipse. Many of the methods are helper methods to easily access things like viewScope etc, which is easy from SSJS but less easy from Java. Most are pretty self-explanatory.
Content assist doesn't seem to work from SSJS, but will from any Java class or, alternatively, open up one of the Java classes created for XPages / Custom Controls under the "local" package in Package Explorer, type "ExtLibUtil." in any method and you'll see the list.
I want to add a new section in control panel of liferay and within that section I want to have my custom-portlet. I did it using ext. However I want to do it with hook . Is it possible ?
I don't think it would be that easy with a hook, because of the following reasons:
You can't modify in a Hook - the class com.liferay.portal.util.PortletCategoryKeys which contains the keys for displaying the different sections. The different sections are hard-coded in this class in a String array ALL.
You can't modify the logic of PortalImpl#isControlPanelPortlet() which uses the PortletCategoryKeys#ALL to determine if the request in question is for a control panel portlet.
Then you also have another method which you can't modify with a Hook and is used extensively PortalImpl#getControlPanelCategory()
Doing it with a hook:
I have not tried this but I think if you need to do it with a hook you would have to change all those JSPs which make use of PortletCategoryKeys#ALL and the methods of PortalImpl as stated above, and provide your custom implementation for all these methods in the JSP.
I would really like to know how you implemented it with an EXT may be just the steps or the methods you have overridden. So that I can try to convert those in terms of a hook.
This is as far as my understanding goes. Hope this helps.
With the advent of Marketplace, ControlPanel has a new category named "Marketplace" and that section is introduced in a plugin. However, I never checked if 6.1 GA2 introduced a new section that this plugin just fills. Check the marketplace plugin if you can find a trace of this section implemented there.
On the other hand, nobody has yet named any section that definitely required a new section (though some have asked me how to solve the same problem). For this reason, you might want to re-think the requirement and choose one of the existing sections. If you don't, at least I'd be interested in the name and purpose of the new section - I might find a first one actually justifying this kind of implementation...