One thing that I really like about behave ( https://behave.readthedocs.io/en/stable/ ) is that you can use the stage flag and it will run different step implementations for each one. If you pass the flag --stage=ui, then all step implementations inside ui_steps will run.
I don't want to be stuck with behave, but I didn't see this feature in other runner ( like cucumber.js or even cucumber for java)
Any ideia on how to implement this?
I believe this is possible in cucumberjs. You can pass the location of step deps for cucumber runner. If you have step definitions in separate folders for api and ui tests, you can change your configuration accordingly in your npm script or configuration of the automation tool being used.
You can have two sets of support code and specify which to use via the CLI with --require. Like many things this is easier to manage using profiles.
Aslak (the creator of Cucumber) has a good talk where he is doing something similar to this, using different support code against the same features and steps to test different parts of the stack:
https://www.youtube.com/watch?v=sUclXYMDI94
Related
I want to create CI on Github Action for QA Automation. But there is multiple language are use to install dependecies. Can i use NodeJS and Golang at the same file?
I read the documentation of Github Action, but there is configuration for each language not both. Any reference or idea i can use?
In short, you write a manifest file (in YAML) and tell GitHub Actions build agent(s) to execute the commands you wanted in an automatic way. See, there is nothing there bind to a single programming language.
You see per language samples/tutorials, simply because that's how new users/developers to get started with a CI/CD system, and it is easy to write up the necessary steps if focusing on the ecosystem of a single programming language.
The underlying GitHub Actions build machines (if managed by GitHub), however, have almost everything pre-installed, so of course you can use Node.js and Golang tools in the same manifest and you don't need any specific reference.
Open the image pages and learn what tools are preinstalled if you like.
Try it out by combining multiple manifests into the single one, and you will see how it works out.
I am able to run the Cucumber/groovy (with maven/pom.xml) test locally. I'm trying to import the test results (results.jon) generated by cucumber to Jira with Xray.
I'm unable to find the steps or procedures required for this. The only source found: https://confluence.xpand-it.com/display/public/XRAY/Import+Execution+Results
but not applicable to my project. There is no CICD yet at the moment. Is there any way to generate results/reports imported to Jira every time I run a test/multiple tests?
For Gherkin-based frameworks, such as Cucumber, you can't simply submit the results. This is because Xray needs to have the Gherkin phrases, which cannot be inferred from the results file.
So you need to choose one of the possible cucumber flows. You need to either choose Xray as the master for the edition of Cucumber scenarios, or you need to use Git/SVN for that and then synch them to Xray.
These steps are detailed in the previous link.
You can see some useful tutorials here.
There are some cucumber specific tutorials, such as this one, but they're not fully detailed. You can see a more technically detailed tutorial for Serenity BDD that make those steps more visible, for the two different flows (you'll need then to adapt it to cucumber specifics, but the principles are the same).
At the moment, I'm using two different frameworks for REST APIs integration testing, and load/stress testing. Respectively : geb (or cucumber) and gatling. But most of the time, I'm re-writing some pieces of code in load / performance scenarii that I've been writing for integration testing.
So the question is : is there a framework (running on the JVM) or simply a way, to write integration tests (for a strict REST API use case), preferably programmatically, then assemble load testing scenarios using these integration tests.
I've read cucumber maybe could do that, but I'm lacking a proper example.
The requirements :
write integration tests programmatically
for any integration test, have the ability to "extract" values (the same way gatling can extract json paths for instance)
assemble the integration tests in a load test scenario
If anyone has some experience to share, I'd be happy to read any blog article, GitHub repository, or whatever source dealing with such an approach.
Thanks in advance for your help.
It sounds like you want to extract a library that you use both for your integration tests as well as your load test.
Both tools you are referring to are able to use external jar.
Suppose that you use Maven or Gradle as build tool, create a new module that you refer to from both your integration tests and your load tests. Place all interaction logic in this new module. This should allow you to reuse the code you need.
I am developing a (Groovy) application that I build via Gradle (on a Continuous Integration server). That application should be compiled into two versions: one development build (including some features I only want to enable for myself), and one public build (which would not include or just disable those "development features").
One solution to this would be to have something like a global flag directly in the main class of the application, something like static final boolean PUBLIC_RELEASE. Then within my code I could check for that flag and enable or disable a certain feature.
Now in my Gradle build script I could check for an environment variable (set by the Continuous Integration server). If that variable is set, then I could set (i.e. change) the current value of the flag to either true or false before the sources are being compiled.
I am sure that approach would work. However, it does not feel right to modify the sources themselves during the build process. On the other hand I would assume this is kind of a standard task for many software projects.
Is there any "best practice" to deal with this requirement?
Is can work out three way for handling the scenario - ordered in the way I would do that:
Create a dedicated properties file the is filtered during build and added to the final jar. Application behavior is determined by this file on runtime. Basically this is how such scenario is handled, but such file can be modified in jar directly by the user.
Source code filtering, hint ReplaceTokens. This seems the best way of securing the application, since the behavior is compiled into code directly, but also problematic when it comes to filtering.
Configure the behavior of application by passing system properties -D at runtime. There's a possibility that a lot of such properties should be passed so it might be problematic for the end user and the configuration of the application is explicitly exposed.
I've been doing some work testing web applications with Cucumber and I currently have a number of steps set up to run with Culerity. This works well, but there are times when it would be nice to run the exact same stories in Selenium.
I see two possible approaches that may work:
Writing each step so that it performs the step appropriately depending on the value of some global variable.
Having separate step definition files and somehow selectively including the correct one.
What is the preferred method for accomplishing this?
Third option: See if Culerity implements the Webrat API. Its README file says: "Culerity lets you (...) reuse existing Webrat-Style step definitions". Couldn't find much more than that though. Ideally, you would be able to switch backends with a config option or command-line argument without having to touch the step definitions.
Of course this would only work if you're not testing Javascript, which Culerity supports, but Webrat doesn't.
HI, have you looked at Capybara? It will allow you to use a variety of web drivers, and will allow you to test javascript-related features as well.
I think this is the one you are looking for. http://robots.thoughtbot.com/post/1658763359/thoughtbot-and-the-holy-grail
You can schedule the tests to run in Jenkins. Local machine Jenkins software is open source. You can get cucumber plugin in Jenkins so that you can achieve reporting part to your project on top of continuous test run