I am still very new in Cucumber-jvm/Selenium, so I am very sorry if the question sounds dumb.
My question is, if I run a feature file as a cucumber feature, do it run #before in different steps file because it search all the steps. If it does then how to make it just run the step I want? I can change the location of the glue code but is that the only solution?
Background: I'm an intern in a big company. I'm doing an automated software testing for a product. There is already an existing automated test steps. What we're going to do is to extend the project and add our own steps. I created a new simple steps class and feature file just to try it out. It doesn't work because every time I run the feature file, it triggers something which I presume #before in different steps. The #before is in every existing steps in the package. The thing work if I change package and do run configuration which I add the location of the glue code. I'm using Eclipse Photon.
Stepdefs and hook methods are global in nature ie. if they are present in the packages defined in the glue option of the runner they will be picked up for each scenario. The way out is to use tags on the hooks which match that on the scenario.
SOmething like
#Before("#TagNew")
#TagNew
Scenario:....
Related
When writing a contract for an API i found myself repeating the same things over and over. For example regex validations for complex json object need to be copy pasted.
Thats tedious and not very DRY.
I'm using Kotlin DSL and Maven
I tried to extract the common parts in another file to reuse it. (Kotlin extension functions ftw.)
After trying multiple things to reuse that file I gave up.
The common parts should be as close to the actual contracts as possible. I don't want to export them in another project, and build them seperat, as they are an vital part of the contracts.
I tried it the following ways:
just put the file in the same directory and importing the functions, hoping it would be resolved as it would in java - did not work at all (my expectations were low, was worth a shot)
putting it in another maven module, and add that as dependency to the spring-cloud-contract-maven-plugin. that worked, as long as the dependant module was built and installed in the local maven repo. if no built version was available maven could not resolve it.
experimenting with kotlin script #file:Import() and #file:DependOn to tackle my issue, no luck.
Is there another way, that I missed? Is there a prefered way doing this?
This must be a common issue, right?
Upon creating a UI target to the app two files will be created in Xcode.
MyAppUITests.swift and info.plist
These both files are placed under the MyAppUITests folder.
The swift class has some default test methods to starts with whereas the plist has the settings info of the created UI test. We are then write test cases, write some utility classes etc. The utility classes also saved under the UI test target. The whole setup works fine with "MyApp".
Requirement: I want to give this setup to some other tester/developer who is a newbie. Means, if they want to implement the UI testing in their app, I want to give them a sample setup which will contain the UI test target with some sample test cases and utility methods.
Current flow: Currently we are having documents regarding the UI test setup, the usage of the written utilities, etc. A person can read those documents and do all the steps manually to setup the UI test environment.
We want to take it to the next level by automate this setup process. Something like, if I keep the sample files in a repo and create a run script that can import the files from repo and add it to the newbie's source code while running. I'm not sure this is possible and I appreciate the suggestions on it.
You should probably do the generic preparation by yourself. Then, with the help of git write a bash script that does this preparation. I suppose you can automate some of the most difficult to automate steps with xcodeproj generators like
https://github.com/yonaskolb/XcodeGen
I'm currently working on a little pet project that takes a code file and deploys it using NuGet. I can currently replace the namespaces in the project using the $rootnamespace$ token and the .pp extension, but I'm curious if there is a better way.
My chief complaint is that I have to take code which builds correctly and transform it temporarily into something that no longer does so.
Is there a way for me to perform these transformations without having to alter my source code directly?
So, I created a very simple NuGet Preprocessor that looks at my solution and creates a shadow copy that has been tokenized and transformed to adhere to the NuGet standard. Works like a charm and now I can very easily deploy source files directly.
We use gradle as our build tool and use the idea plugin to be able to generate the project/module files. The process for a new developer on the project would look like this:
pull from source control.
run 'gradle idea'.
open idea and be able to develop without any further setup.
This all works nicely, but generally only gets exercised when a new developer joins or someone gets a new machine. I would really like to automate the testing of this more frequently in the same way we automate our unit/integration tests as part of our continuous integration process.
Does anyone know if this is possible and if there is any libraries for doing this kind of thing?
You can also substitue idea for eclipse as we have a similar process for those that prefer using eclipse.
The second step (with or without step one) is easy to smoke test (just execute the task as part of a CI build), the third one less so. However, if you are following best practices and regenerate IDEA files rather than committing them to source control, developers will likely perform both steps more or less regularly (e.g. every time a dependency changes).
As Peter noted, the real challenge is step #3. The first 2 ones are solved by your SCM plugin and gradle task. You could try automating the last task by doing something like this
identify the proper command line option, on your platform, that opens a specified intellij project from the command line
find a simple good enough scenario that could validate that the generated project is working as it should. E.g. make a clean then build. Make sure you can reproduce these steps using keyboard shortcuts only. Validation could be made by validating either produced artifacts or test result reports, etc
use an external library, like Robot, to program the starting of intellij and the running of your keyboards. Here's a simple example with Robot. Use a dynamic language with inbuilt console instead of pure Java for that, it will speed your scripting a lot...
Another idea would be to include a daemon plugin in intellij to pass back the commands from external CLI. Otherwise take contact with the intellij team, they may have something to ease your work here.
Notes:
beware of false negatives: any failure could be caused by external issues, like project instability. Try to make sure you only build from a validated working project...
beware of false positives: any assumption / unchecked result code could hide issues. Make sure you clean properly the workspace, installation, to have a repeatable state and standard scenario matching first use.
Final thoughts: while interesting from a theoretical angle, this automation exercise may not bring all the required results, i.e. the validation of the platform. Still it's an interesting learning experience and could serve as a material for a nice short talk, especially if you find out interesting stuff. Make it a beer challenger with your team when you have a few idle hours to try to see who can implement the fastest a working solution ;) Good luck!
A bit of context: I am practicing with the former editions of the Google Code Jam, and trying to solve a lot of these puzzles in Java. For each puzzle I create a specific project in Eclipse.
I also built a little "Sample" solver project containing usual operations on input/output files, handling of test cases, script files to run the program on a file quickly, and so on. Now I am using this framework on every puzzle, simply modifying a core "Solver" class which contain the main algorithm. All other files stay the same on every project.
My problem is, I am versioning my work but clearly the only relevant source code to version for each project is this Solver class (and some input/output files). All the rest is duplicated and I would like it to be easily updated when I modify something in the sample project.
On the other hand, I want to be able to easily checkout a project and get it fully working.
I was thinking of using SVN externals to do this but external definitions apply only to subdirectories - and my relevant files are in the same folders as the duplicated ones.
Also SVN ignore does not fulfill my purposes because I would still have to manually replicate any change to my sample project throughout each project.
Do you know of a good way to handle this? Thanks!
Code reuse is typically not accomplished using the version control system, but using polymorphism or libraries. One disadvantage of using the version control system is that you have to do a svn update to pull the new externals from the repository, which strikes me as awkward if you have many projects checked out. Another thing to consider is the development workflow when modifying the reused code. To test your changes, you will probably want to run them with a particular solver, but to do that, you need to svn update - and I am pretty sure you will forget to every once in while, and wonder why your bugfix has no effect ... Therefore I recommend one of the following two approaches:
Polymorphism
Put all your solvers in the same project, making reuse rather trivial. To invoke the right solver, you could do something like:
interface Solver {
// your methods
}
class Ex1Solver implements Solver {
// your solution
}
public static void main(String[] args) throws Exception {
Solver solver = (Solver) Class.forName(args[0]).newInstance();
// work with solver
}
Library
Define an eclipse project for the reused test harness, and a project for each solution. Declare the reused project as dependency of the solution project (In eclipse, right click on the project -> build path -> configure build path -> projects -> add). The test harness would create the solver in the same way as in the polymorphism solution.
You can use svn:externals with files (starting with 1.6) as well, but i would think about a solution on base of a library, cause it's sound like your "framework" is such a kind of thing.