Is there a naming convention to distinguish .feature files that contain plain Gherkin vs. Karate UI vs. Karate API? [duplicate] - naming-conventions

This question already has answers here:
Can we parameterize the request file name to the Read method in Karate?
(2 answers)
Closed 1 year ago.
You can't reliably determine what a .feature file is for until you open it and look inside. That is, you don’t know if it’s just Gherkin or if it’s Karate API or UI.
Is there some convention to name files more clearly?
I'm considering using this naming convention with my team:
some-file.api.feature for Karate API tests
some-file.ui.feature for Karate UI tests
some-file.feature for plain Gherkin/Cucumber tests

There is no convention. The reason is because you cah have "hybrid" tests which IMO is an under-appreciated test-strategy, because other tools don't support it well.
Here is an example: https://twitter.com/KarateDSL/status/1350743622312894466
And note that you can even do unit-testing: https://twitter.com/KarateDSL/status/1359369240227106816
I'll admit that Karate mocks could have benefited from a different file-extension, but we have some plans for that in the future, perhaps JS.
I think a folder naming convention should be good enough, but just my opinion.

Related

Add Karate custom actions [duplicate]

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

Karate Test Framework with Spring Webflux and Reactive API [duplicate]

This question already has an answer here:
Do Karate support .avro file as an input request?
(1 answer)
Closed 1 year ago.
Can Karate Test Framework work with Spring Webflux where return type is Mono<> and Flux<> Objects rather than the json string. Any refernce would be helpful.
Note that typical Karate usage is at the HTTP layer for REST / GraphQL - so it doesn't matter what the underlying technology is at all. So please re-check what your project requirements are.
There are plenty of examples and tutorials for Spring Boot - just do a search.
That said - Karate has very good Java interop and that may be the solution in this case. I don't know of any examples. But please refer to these answers and that should get you started:
https://stackoverflow.com/a/62826394/143475
Karate: Convert string to karate native variable in javascript

Karate Java API for Match methods

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

Do Karate UI support Angular UI based application testing

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.

Karate vs Spock

I've recently found Karate framework for testing Web Services. But there is also Spock framework providing similar (to my mind) functionality. What are the differences between the frameworks? I would like to suggest our testers to take a look at it.
Developer of Karate here. I have only read about Spock but here's my PoV.
Karate is laser-focused on testing HTTP web-services, and therefore is designed to manipulate and perform assertions on JSON and XML. As a result - you do not need POJO-s any-more.
Whereas Spock is a general-purpose testing framework. It is based on Groovy, so it reduces the verbosity somewhat compared to if you just used Java, and it adds the BDD flavor that is of value in expressing test-cases. Just like Karate, it has a structure to test-cases, a life-cycle (before hooks, environment switching, etc.) data-driven test helpers, and integration with unit-test and reporting frameworks such as JUnit.
A key difference IMO is that while Spock and similar frameworks try to abstract away the verbosity of Java in favor of a cleaner more readable syntax - they succeed only to a certain extent. Karate almost bypasses Java completely (from a test writers PoV) which means that you are operating in the exact 'layer' that you want to - which is HTTP and JSON / XML.
I'd like to point you to this comparison between Karate and REST-assured - since some of the points would apply to Spock as well, and it would be a helpful reference for any team evaluating Karate.
EDIT - Karate's data-driven testing is very similar to Spock, and uses JS (that can do Java interop) instead of Groovy: https://twitter.com/KarateDSL/status/1359369240227106816