I have few feature files in specific subfolders, And I want to execute those feature files according to my defined order.
So how can we run the feature files in a specific order?
Thank you in Advance!
You can create one feature and then make calls to the other features. But this means you will lose the biggest benefit of Karate which is that you can run tests in parallel.
Any needs beyond this, please assume are not supported (or will never be supported) by Karate. Also read this: https://stackoverflow.com/a/46080568/143475
Related
I read in the documentation that we can run multiple feature files by adding newer lines for different classpaths in the simulation class. Is there a way wherein we can run multiple feature files belonging to the same package just like we run in FeatureRunner files?
No, I personally think that will introduce maintainability issues. We will consider PR-s though if anyone wants to contribute this.
If you really want this behavior, you should be able to write a small bit of Java code that scans a folder, loops over them and builds the Gatling "scenarios".
So for re usability, how can I reuse some particular amount of code from one feature file to other feature file.
I don't want to keep functions outside in js files.
As of now, this is not possible with karate.
IMHO, this is not even valid enhancement request. If you really want to reuse the code, it would be better idea to keep outside of feature file in js function and calling them from different feature files as and when needed.
Peter Thomas, author of Karate, mentioned here that reuse of feature is possible and one cannot reuse the particular scenario from feature file.
I don't want to keep functions outside in js files.
You don't have to. Please read the documentation. There are multiple ways for code-reuse:
the call keyword for re-usable features
Background / hooks
calling Java
Was wondering if I could get setup cucumber-reporting for specific folders?
For example in the https://github.com/intuit/karate#naming-conventions, in CatsRunner.java i set up the third party cucumber reporting? without parallel execution. please advise or direct me on how to set it up.
Rationale. its easier to read and helps me in debugging
You are always recommended to use the 3rd party Cucumber Reporting when you want HTML reports. And you can create as many Java classes similar to the DemoTestParallel in different packages. The first argument to CucumberRunner.parallel() needs to be a Java class - and by default, the same package and sub-folders will be scanned for *.feature files.
BUT I think your question is simply how to easily debug a single feature in dev-mode. Easy, just use the #RunWith(Karate.class) JUnit runner: video | documentation
I have some Cucumber scenarios, for which I created the following files:
create_extended_search.feature
activate_extended_search.feature
edit_extended_search.feature
delete_extended_search.feature
Within these files, I have several scenarios.
Three of the files use the same background, and it would be nice to be able to place it into one file (e.g. support/backgrounds.rb) and then reference it from the feature files.
Is this possible somehow? Thanks.
I believe you would have to create a step that is made up of the steps in your current background. Then call that step in the background for each feature.
There's no notion of 'include'ing feature files in Cucumber. As Justin points out, you can create a single step representing what you want as a background, and call that where appropriate. An alternative is to use a Before hook to perform certain tasks in advance of scenarios that you mark with a specific tag.
Personally, I'd treat this problem as something of a red flag, and start asking if my feature files were split up in the best way possible. Frequently if I find myself bemoaning the inability to include other feature files, or conversely, wishing I could exclude certain scenarios from running my background, it's a very strong sign that my feature files are too finely sliced up, or I'm trying to cram unrelated functionality together and need to split it up further.
I've been trying to figure out if there is already an accepted method for testing file io operations in Haskell, but I have yet to find any information that is useful for what I am trying to do.
I'm writing a small library that performs various file system operations (recursively traverse a directory and return a list of all files; sync multiple directories so that each directory contains the same files using inodes as the equality test and hardlinks...) and I want to make sure that they actually work, but the only way I can think of to test them is to create a temporary directory with a known structure and compare the results from the functions executed on this temporary directory with the known results. The thing is, I would like to get as much test coverage as possible while still being mainly automated: I don't want to have create the directory structure by hand.
I have searched google and hackage, but the packages that I have seen on hackage do not use any testing -- maybe I just picked the wrong ones -- and anything I find on google does not deal with IO testing.
Any help would be appreciated
Thanks, James
Maybe you can find a way to make this work for you.
EDIT:
the packages that I have seen on hackage do not use any testing
I have found an unit testing framework for Haskell on Hackage. Including this framework, maybe you could use assertions to verify that the files you require are present in the directories that you want them to be and they correspond to their intended purpose.
HUnit is the usual library for IO-based tests. I don't know of a set of properties/combinators for file actions -- that would be useful.
There is no reason why your test code cannot create a temporary directory, and check its contents after running your impure code.
If you want mainly automated testing of monadic code, you might want to look into Monadic QuickCheck. You can write down properties that you think should be true, such as
If you create a file with read permission, it will be possible to open the file for reading.
If you remove a file, it won't open.
Whatever else you think of...
QuickCheck will then generate random tests.