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
Related
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
For me to execute something at the TestRun, Feature, Scenario or Step level.. I understand we can use Hooks. What i would like to find out is how these can be writte in the feature file when I am writting the spec.
Based on my understanding I can use Backgroud to write something common which is to be run within the feature before all the scenarios. However its adviced that we should not have long list in the Backgroud section. Also if I have something which is common for the testrun or multiple feature where i can use a tag a group them, is there any syntax I can use to write this.
The hook implementations cannot be expressed in Gherkin in the feature files, they must be implemented in the step implementation files:
Tag the scenarios and/or features with a tag #foo, and in some class decorated with the [Binding] attribute, annotate a method with a hook attribute, like [BeforeTestRun("foo")].
More information and available hooks can be found in the specflow wiki.
If you're worried about having a long list of steps in the Background, maybe the steps are too verbose and you can consider joining them into a single step. If you need to do something for all tests in the test run, maybe it's not important to mention it in the feature anyways, so it can go in a step implementation file like described above.
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.
In a Rails 3.1 app, one controller needs to have all its views compile whatever Sass stylesheets they might need per request using a set of custom variables. Ideally, the compilation must happen via the asset pipeline so that content-based asset names (ones that include an MD5 hash of the content) are generated. It is important for the solution to use pure Sass capabilities as opposed to resorting to, for example, ERB processing of Sass stylesheets.
From the research I've done here and elsewhere, the following seems like a possible approach:
Set up variable access
Create some type of variable accessor bridge using custom Sass functions, e.g., as described by Konstantin Haase here (gist). This seems pretty easy to do.
Configure all variable access via a Sass partial, e.g., in _base.sass which is the Compass way. The partial can use the custom functions defined above. Also easy.
Capture all asset references
Decorate the asset_path method of the view object. I have this working well.
Resolve references using a custom subclass of Sprockets::Environment. This is also working well.
Force asset recompilation, regardless of file modification times
I have not found a good solution for this yet.
I've seen examples of kicking off Sass processing manually by instantiating a new Sass::Engine and passing custom data that will be available in Sass::Script::Functions::EvaluationContext. The problem with this approach is that I'd have to manage file naming and paths myself and I'd always run the risk of possible deviation from what Sprockets does.
I wasn't able to find any examples of forcing Sprockets processing on a per-request basis, regardless of file mod times, that also allows for custom variable passing.
I'd appreciate comments on the general approach as well as any specific pointers/suggestions on how to best handle (3).
Sim.
It is possible. Look here SASS: Set variable at compile time
I wrote a solution to address it, I'll post soon and push it here, in case you or someone else still need it.
SASS is designed to be pre-compiled to CSS. Having Sprockets do this for every request for a view on a per request basis is not going to perform very well. Every request is going to have to wait for the compilation to be done, and it is not fast (from a serving-pages point of view).
The MD5 generation is within Sprockets, so if you are changing custom variables you are going to have to force a compilation on every single request to make sure that changes are seen because the view is (probably) not going to know.
It sounds as though this is not really in the sweet-spot of the asset-pipeline, and you should look at doing something more optimised for truly dynamic CSS.
Sorry. :-)
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.