This question already has an answer here:
Do Karate support .avro file as an input request?
(1 answer)
Closed 1 year ago.
Beyond the interfaces that you offer out of the box, we have some other interfaces which need to be integrated within E2E tests. Those are TCP based protocols.
Is there any chance that you will make karate extendable any time soon so that we can make such calls in actions like statements and not via JS/Java API?
We would need something like
... REST API Test
And send customProtocol message(attr1=1,attr2=2)
Then expect customProtocol message(res=OK)
... GUI Test
Karate is already "extendable" via Java interop. If you use Java interop, you will need one extra line to "import" the API you need. And yes, you will not get the "natural language" look that you seem to be after, but in my honest opinion, all of that is very over rated.
So if the extra line and using an API that looks like Java in a feature file is a deal-breaker for you, you may need to look for some other framework.
Please take a look at this example, where you can get close to a custom DSL using the JS or Java-interop approach: https://twitter.com/getkarate/status/1144458169822806016
I also think that for your TCP based protocol, this answer directly answers your question: https://stackoverflow.com/a/62826394/143475
Related
I have created a Java object in karate scripts using Java interop and have used it as required.
Now, I want to retrieve that same instance in another Java class. Is there a way to do that?
In karate, we have an equivalent method like karate.get('objectName'). Is there any equivalent API available in Karate lib?
Please assume that the answer is no. I'd like to mention that the whole point of creating Karate was to avoid using Java for API test automation. I say this because I suspect based on your questions that you have made the same mistake I've seen a few other teams make - which is attempting to make Karate work like the Seleniums and Rest Assureds of the world. That always ends badly. And what's worse is that these teams blame Karate for that and go around telling everyone. I'd rather have that not happen - so if this is a "blocker" please consider using some other tool.
If you are already calling Java, you have plenty of ways to pass objects around right? Just use that and don't over-complicate your tests. Or you can use the "singleton" pattern, nothing to do with Karate, you can look it up.
Background:
I noticed this interesting post on Twitter about a Java API for Karate: https://twitter.com/ptrthomas/status/1344290316212342784
I don't have a twitter account so unable to reply - hope you don't mind me asking here instead.
I have used Karate (with the parallel runner, feature files and all) in one work project and it is a joy to use - and a few folks in the workplace are very impressed with the complex JSON assertion. We are achieving a level of JSON response field coverage for that project that is not possible with other frameworks (IMO).
I've now been tasked with improving an older test project which uses JUnit + RESTAssured, but has quite limited field assertions. I am unable to fully convert it to raw Karate (too many tests, not enough time), but I'm keen to explore the possibility of supplementing what is there already with the Karate Java API mentioned in above twitter post.
For example - for an existing test which gets a Response using RESTAssured, it would be nice for me to somehow use the 'contains' method (or any of the methods in Match class) in Karate to assert that response, as it is the best JSON assertion tool I have come across.
Questions:
Off the bat - is this a practice you would recommend for my use case? Let me know if you think this is an anti-pattern. I ask this because the example here (https://github.com/ptrthomas/karate-showcase) is not using RESTAssured to get the response and my use case is a bit different.
If its worth exploring - I assume this stuff will be available in v1.0.0? (I see public methods such as that are on the develop branch, but couldn't see it on the v1.0.0 github thread).
but I'm keen to explore the possibility of supplementing what is there already with the Karate Java API mentioned in above twitter post.
That's very interesting and you have got me also thinking about this potentially interesting way to introduce Karate to legacy projects. I do get this question on how to magically migrate existing RA tests a lot.
I would recommend it. You can expect a 0.9.9.RC3 next week that should have all the assertions you want. And the API has been simplified so you don't need to call isTrue() etc.
We plan to have better examples (maybe you can help) but for now, use this as a starting point (look at the last test / very end of the file): MatchTest.java
If you want to get started now (which I recommend and you can provide more feedback) do take a look at the developer guide: https://github.com/intuit/karate/wiki/Developer-Guide
If karate supports Angular testing, can i have some example so that i can look into it.
Have been going through locators given at https://intuit.github.io/karate/karate-core/#locators but unable to get exact information on how to proceed.
There is no need, Karate works with plain HTML.
And if you need to do some specifc JS helpers (which is all that frameworks that claim to support Angular do), just use the tips here and make re-usable functions: https://stackoverflow.com/a/60800181/143475
If you still have a question, ask a new question and provide a sample (can be online, see examples in link above) for us to understand and discuss.
I've spent the last few days trying to understand if I should use api blueprint, RAML or swagger.
It looks like swagger has the biggest community but the closer I look the more I feel that it greatly lacks in documentation (I was forced to look at the code many times to try and integrate it with my current project), many github issues and stackoverflow questions are unanswered.
Is it possible that I am missing something here?
All I want is a tool to help me write the API documentation and test the endpoints.
Why must swagger become part of the server logic?? If I create swagger files in the editor and then serve them to the UI directly it breaks..
As far as I can tell it even makes the server slightly slower and forces the existence of many clumsily maintained integrations :p What am I missing here?
We're trying to work a lot on improving the documentation of Swagger. It's a bit more difficult when many of the projects are community-driven and not managed by a single organization.
We actually try to reply to issues on github quickly (we don't always succeed) and we have our own google group for general questions so we follow stackoverflow somewhat less.
The editor you mention is a new tool as part of the work on Swagger 2.0 and it's not final yet. As such, it still have a few bugs and missing features. The UI is also in the process of being adapted to Swagger 2.0 and the same limitations apply to it.
You most certainly don't have to integrate it with your server and you can expose the documentation statically. The advantage of integrating it with the server is that it's easier to maintain if the API changes.
You can try RAML + ramlev + Abao
The steps should be
Write API Spec in RAML with your fav editor, ie. Atom, vim
Validate your RAML with ramlev
Implement the server logic according API Spec
Validate server logic with Abao
In the bad old days of interactive console applications, Don Libes created a tool called Expect, which enabled you to write Tcl scripts that interacted with these applications, much as a user would. Expect had two tremendous benefits:
It was possible to script interactions that otherwise would have had to be repeated by hand, tediously. A classic example was dialup Internet access hell (from the days before PPP).
It was possible to write scripts to test one's own interactive applications, programmatically, as part of a regression suite.
Today most interactive applications are on the web, not on the console. Hence my question: is there any tool that provides the ability to interact with web pages and web forms programmatically, much as Expect provides the ability to interact with console applications programmatically?
(The closest thing I am aware of is Chickenfoot.)
You might be looking for Selenium
I've used Selenium RC in conjunction with Python to drive web page interactions programmatically. This has allowed me to write pretty extensive user tests in which forms and inputs are driven and their results are measured.
Check out the Selenium IDE on Firefox (as mentioned above). It allows you to record tests in the browser and play them back, either using the IDE itself, or the Remote Control app.
Perl Mechanize works pretty well for this exact issue.
HTTPS and some authentication issues are tricky at times. I will be posting couple questions about those in the future.
I did a ton of Expect work in a former life and always thought Don Libes' Expect book was one of the best-written and most enlightening technical books I'd ever seen.
Hands down I would say that Perl's WWW::Mechanize library is what you want. I note above that you were having trouble finding documentation. There is good documentation for it! Look up the module's distribution on search.cpan.org and see what all is packaged with it. There's a FAQ, Cookbook with examples, etc. Plus I've always been able to get help on the web. If you can't get it here, try at use.perl.org or perlmonks.org. WWW::Mechanize's author, Andy Lester, is present on Stack Overflow. (He's also an all around friendly and helpful guy.)
I believe WWW::Mechanize also has a program that is analogous to Expect's autoexpect program: you set up a proxy process running this program as a server, point your browser to it as a proxy, perform the actions you want to automate, and then the proxy program gives you a WWW::Mechanize program for you to use as a base for your project. (If it works like autoexpect, you will certainly want to make modifications from there.)
As mentioned above, WWW::Mechanize is a browser (to be more exact, it is a web client or http client) that happens to be programmable. The last time I looked, there was even work in progress to make it support JavaScript.
In addition to Selenium, if you're doing the Ruby/Rails thing, there's Webrat.