The cucumber-jvm javadocs states that purpose of the glue element is to specify the location of the stepdefinitions and hooks. However, this doesn't seem to work for me. Lets say I have my features in directory a, and my step definitions in directory b. Then,
#Cucumber.Options(
features= "directory_a",
glue="directory_b"
)
will load my feature files from directory_a, but, it doesn't load my step definitions from directly_b. However, if I use
#Cucumber.Options(
features= {"directory_a", "directory_b"}
)
then my features from directory_a is loaded, and my step definitions from directory_b are also picked up. Which is exactly what I want, however, I don't understand why the former isn't working? I'm guessing it has something to do with it expecting the URI to be formatted differently (maybe i need to prepend a classpath:// or something like that), but I can't find any information on this in the documentation.
I have successfully used something like:
#RunWith(Cucumber.class)
#Cucumber.Options(
//this code will only look into "features/" folder for features
features={"classpath:features/"},
glue = { "com.mycompany.cucumber.stepdefinitions", "com.mycompany.cucumber.hooks" },
format = { "com.mycompany.cucumber.formatter.RuntimeInfoCatcher", "json:target/cucumber.json" },
tags = { "#working" }
)
public class CucumberStarterIT {
}
Looking at the doc at http://cukes.info/api/cucumber/jvm/javadoc/cucumber/api/junit/Cucumber.Options.html it specifies the options to be of type String[] so perhaps it's not expected to work "well" if you don't give it a single-value list. Try glue={"directory_b"} and see what happens for you.
I had this problem too... and so far it seems to be that:
"features" is looking for a filesystem path:
features = "src/foo/bar"
whereas "glue" is looking for a package name:
glue = "foo.bar"
Not sure why they are different, but this seems to be working for me.
Hi as per my knowledge it all depends on the structure of you project. For example if you add the "Directory_a" ( directory which contains feature files) in the root level and StepDefinition, Hooks at src > test > java "Directory_b" And the TestRunner class at the same level ( src > test > java ) in "Directory_c"
Dir_a
|
src
|---main
|---test
|------java
|------Dir_b
|------Dir_c
You saying "Dir_b" while you are in the "Dir_c" It will identify "Dir_b" or any directory in same level with out any additional paths so,
It will be
glue = {"Dir_b"},
But when you look at the directory that includes feature file you have to give the path from the root level
In this case it's
features = {"Dir_a"}
or Giving the actual path eg :- "E://Project_Name//Dir_a" should work too
If your feature directory is NOT in root level make sure you give the path like "src/path to feature directory"
It will work fine :)
Related
I'm working on a Kotlin multi-platform project, and I need my JS tests to run on Node.js but with custom command line arguments (specifically I need node to run with the --expose-gc flag, because some tests need to trigger garbage collection).
Looking at the documentation for the Gradle Kotlin JS DSL I didn't find any mention of how to do that; does anyone know whether it's at all possible and how?
Unfortunately can not answer your question directly, but there is some suggestion to help you with reverse engineering.
Let's start from some example. We have Gradle tasks to run our project using webpack's dev server such as browserDevelopmentRun, browserProductionRun (not sure if multi-platform projects have it, but JS projects do). We can add:
println(tasks.named("browserProductionRun").get().javaClass)
to build.gradle.kts to find out the exact class used for this task. When we sync Gradle, it outputs:
org.jetbrains.kotlin.gradle.targets.js.webpack.KotlinWebpack_Decorated
Now we know the exact class of this task so we can investigate its API. The auto completion or navigating inside of the KotlinWebpack class helps us to find out that it has a helpful nodeArgs property to configure NodeJS arguments for it, so we can set them, for example:
tasks.named("browserProductionRun", org.jetbrains.kotlin.gradle.targets.js.webpack.KotlinWebpack::class).get().nodeArgs.add("--trace-deprecation")
Getting back to your question.
In your case I guess you need to investigate the browserTest task. Let's get some info about it by adding:
println(tasks.named("browserTest").get().javaClass)
to build.gradle.kts - a-ha - it seems to be of the org.jetbrains.kotlin.gradle.targets.js.testing.KotlinJsTest_Decorated type. Let's check what's inside. Open KotlinJsTest.kt somehow - for example by typing its name into the window being opened by CMD + Shift + O (make sure to select "All Places" here) or just by typing its name somewhere in build.gradle.kts and navigating inside it.
The only interesting thing I see inside this open class is the following block:
override fun createTestExecutionSpec(): TCServiceMessagesTestExecutionSpec {
val forkOptions = DefaultProcessForkOptions(fileResolver)
forkOptions.workingDir = npmProject.dir
forkOptions.executable = nodeJs.requireConfigured().nodeExecutable
val nodeJsArgs = mutableListOf<String>()
return testFramework!!.createTestExecutionSpec(
task = this,
forkOptions = forkOptions,
nodeJsArgs = nodeJsArgs,
debug = debug
)
}
So maybe it can work out to create your own extension of this class, override its createTestExecutionSpec method and provide nodeJsArgs as you need inside it. After that you'll be needing to declare another Gradle task to launch tests inside build.gradle.kts which will use this new extended class.
I am trying to set a module's source (this IS NOT a resource) based on a conditional trigger but it looks like the module is getting fired before the logic is applied:
module "my_module" {
source = "${var.my_field == "" ? var.standard_repo : var.custom_repo}"
stuff...
more stuff...
}
I have created the standard_repo and custom_repo vars as well and defined with URLs for respective repos (using git:: -- this all works w/o conditional)
All this being said, anyone know of a way to implement this conditional aspect? (again, this is a module and not a resource)
I tried using duplicate modules and calling based off the var value but this, too, does not work (condition is never met, even when it is):
repo = ["${var.my_field == "na" ? module.my_module_old : module.my_module_new}"]
One way to achieve this is described in this post
Basically, a common pattern is to have several folders for different environments such as dev/tst/prd. These environments often reuse large parts of the codebase. Some may be abstracted as modules, but there is still often a large common file which is either copy-pasted or symlinked.
The post offers a way that doesn't conditionally disable based on variables but it probably solves your issue of enabling a module based on different enviornments. It makes use of the override feature of terraform and adds a infra_override.tf file. Here, it defines a different source for the module which points to an empty directory. Voila, a disabled module.
Variables are not allowed to be used in the module source parameter. There also does not seem to be a plan for this to change. https://github.com/hashicorp/terraform/issues/1439 . Creating a wrapper script , or using something like mustache http://mustache.github.io/ seems to be the best way to solve the problem.
I have created a package and am now creating my tests within the package. For one test my inputs are a set of files and my outputs will be a different set a files created within the test.
I am saving the input files in the test directory of my package and would like to save the output files there too. Since others may run this test, I do not want to specify the input/output file location using my own path eg /home/myname/.julia/v4.0/MyPackage/test/MyInputFile.txt
How do I specify that the input location is within the package's test folder?
So basically how do I tell Julia to look in the packages's folder under the test directory and not have to worry about specifying the entire path including user name etc?
For example currently I have to say
readtable(/home/myname/.julia/v4.0/MyPackage/test/MyInputFile.txt, separator = '\t', header = false)
But I'd like to just be able to say
readtable(/MyPackage/test/MyInputFile.txt, separator = '\t', header = false)
so that no matter who the user of the package is and where they may store the package, they can still run the test?
I know that LOAD_PATH gives the path Julia looks for packages but I can't find any information on where it looks when importing files.
joinpath(Pkg.dir("MyPackage"), "test") is what you need.
As #GnimucK mentioned in a comment, a better solution is
dirname(#__FILE__)
Why is this better? A package could be installed and used from somewhere else (not the standard package directory). Pkg.dir is "stupid" and does not know better. This is rare, of course, and in most cases it won't matter.
Is it possible to parameterise a feature file in the same way it is a scenario? So each scenario in the feature could refer to some variables which are later defined by a single table for the entire feature file?
All of the answers I've found so far (Feature and scenario outline name in cucumber before hook for example) use Ruby meta-programming, which doesn't inspire much hope for the jvm setup I'm using.
No its not, and for good reason. Feature files are meant to be simple and readable, they are not for programming. Even using scenario outlines and tables is generally not a good thing, so taking this further and having a feature that cannot be understood without reading some other thing that defines variables is counter productive.
You can however put all your variables and stuff in step definitions and write your feature at a higher level of abstraction. You'll find implementing this much easier, as you can use a programming language (which is good at this stuff).
One way of parameterising a feature file is to generate it from a template at compile-time. Then at runtime your cucumber runner executes the generated feature file.
This is fairly easy to do if you are using gradle. Here is an example:
In build.gradle, add groovy code like this:
import groovy.text.GStringTemplateEngine
task generateFeatureFiles {
doFirst {
File featuresDir = new File(sourceSets.main.output.resourcesDir, "features")
File templateFile = new File(featuresDir, "myFeature.template")
def(String bestDay, String currentDay) = ["Friday", "Sunday"]
File featureFile = new File(featuresDir, "${bestDay}-${currentDay}.feature")
Map bindings = [bestDay: bestDay, currentDay: currentDay]
String featureText = new GStringTemplateEngine().createTemplate(templateFile).make(bindings)
featureFile.text = featureText
}
}
processResources.finalizedBy(generateFeatureFiles)
myFeature.template is in the src/main/resources/features directory and might look like this:
Feature: Is it $bestDay yet?
Everybody wants to know when it's $bestDay
Scenario: $currentDay isn't $bestDay
Given today is $currentDay
When I ask whether it's $bestDay yet
Then I should be told "Nope"
Running the build task will create a Friday-Sunday.feature file in build/src/main/resources with the bestDay and currentDay parameters filled in.
The generateFeatureFiles custom task runs immediately after the processResources task. The generated feature file can then be executed by the cucumber runner.
You could generate any number of feature files from the feature template file. The code could read in parameters from a config file in your resources directory for example.
I have learned from the sencha doc how to create a simple MVC application, and now I wonder if it is possible to move from this structure :
-app
--Controller
---controller1.js
---controller2.js
...
--Model
---model1.js
---model2.js
...
--Store
---store1.js
---store2.js
...
--View
---view1.js
---view2.js
...
to this modular structure :
-app
--Module1
---controller.js
---model.js
---store.js
---view.js
--Module2
---controller.js
---model.js
---store.js
---view.js
I want also if you can advise me about the modular structure (good, bad, complex, remarks...), Thank you in advance.
You can do whatever you want with different file and class names. Just remember to keep class name in sync with its position in the file hierarchy. For example if you have class
MyApp.controller.Controller1
located in the following file
- app\Controller\Controller1.js
If you move it to the
- app\module1\Controller.js
You would need to rename class name to
MyApp.module1.Controller
See for yourself whether having such class hierarchy would be appropriate for you. I would not do this. We keep all code according to ExtJs MVC directory structure (mostly). We have the following directories
- store
-- base
- view
-- base
- controller
- model
We usually put base classes underneath special base director to easily separate them from the rest of code.