I want to be able to branch my code when Playwright is running tests. Is there a variable that is available? I have tried playwright.
(the reason I want to branch my code is because urql cache exchange doesn't play nicely with Playwright)
Related
What are the persistence options for fitnesse files? So far it seems like a file system is the only thing supported. There does appear to be an out of date database plugin. Is there anything else that is supported (S3, database, etc.)? Is there a way to control where files are persisted if using the filesystem?
I believe there is very little in that area. The location of the files can be controlled using a command line option. See http://fitnesse.org/FitNesse.FullReferenceGuide.UserGuide.QuickReferenceGuide#FitNesseCommandLINE
-d /path/to/fitnesse/root
How I've used the FitNesse wiki is as a local development tool, with the pages on the file system. Once I'm satisfied with the tests I commit them to version control (e.g. git) so that they become part of the (integration) test pipeline setup (e.g. they are run as part of the CI/CD pipeline of the project).
There is a plugin I believe that will automatically commit any save actions to Git, but I've never used that. Saving each edit action just pollutes version control in my opinion. I only want to see tests after they have been checked/completed, and that tends not to be each save.
Working on a shared wiki environment (where I would expect a non-file system approach would fit in) you run into the same problem, I expect. Developing automated tests is a development task that requires some iterations before it is 'done', and not all attempts reach that 'done' state. So using shared storage for wiki persistence creates 'noise' in the test-set: which are the tests that form the current reference set that should pass and what is work in-progress.
If you are working on a larger project where new features are developed together with their automated tests it becomes even more important to know which test changes belong to which features/changes. Having tests on the file system, in version control, allows you to develop test in sync with code changes in the same branch. This is what I would recommend.
Wanting to update a ".env" properties value, so that the next execution has a new value.
loggingUtils.info("${env.testVar}")
env.testVar = "cat"
loggingUtils.info("${env.testVar}")
Currently what happens is if I configure the "env.testVar" to have a value of "dog" from within jenkins the print statements will be:
dog
cat
but the next time I execute I want it to be
cat
cat
However, it is always just
dog
cat
Is there a way to achieve setting the environment variables so that future builds will have the new variable? I would prefer to do this without a plugin if possible
Builds (can be thought of as "instances of executions") in Jenkins are independent of each other.
If you are trying to tie builds together by transmuting information across builds I would encourage you to think about what you are really trying to do and suggest you might not doing Continuous Integration properly.
Each time you execute a build it starts from scratch. Continuous Integration always starts with what's in source control. Nothing derived should be committed to source control.
I would suggest environment configuration should normally by stored in config files in source control and applied as appropriate via parameters to a build. (i.e what environment do I want to deploy a given build to?).
I'm writing a TFS / VSTS integration with our server by using extension.
I want to present extra data after the build, specifically I want to show an IFRAME and navigate to our server, to a specific URL, determined in part by a dynamically generated unique string.
I have the function that generates the string, but I need to set it as an environment variable before the tests start to run. This is important because the tests need to create that string on the server.
I searched the documentation, examples and other places, but couldn't find a complete example that sets a dynamically generated environment variable and then runs tests.
How do I do it?
You can add/set an environment variable through Logging Commands (e.g. PS: Write-Host "##vso[task.setvariable variable=testvar;]testvalue"), then the following tasks can get this variable as general variable.
With Logging Commands, you also can add additional information in build summary. (##vso[task.uploadsummary]local file path)
You also can deploy a build result extension to display additional information. vsts-extension-samples
I've this Routific API-Key, and i want it not to expose while running Circle Ci tests. And without hitting on it i can pass my specs. How can i not expose my API-KEY and still be able to pass the tests?
You can set them through the Project Settings > Environment Variables section of CirclCI - https://circleci.com/docs/1.0/environment-variables/#setting-environment-variables-for-all-commands-without-adding-them-to-git , which will make them only available in your runs of the project tests and not in your code repo. Alternatively you can create an encrypted file - https://circleci.com/docs/1.0/environment-variables/#keeping-encrypted-environment-variables-in-source-code - in your code and then set the key in the Environment variables section of CircleCI
I requested Routific locally for once and then received the response and saved it. Made a factory a factory which had this response and then used accordingly where needed. In my conditions, this was the only way i could go for, as the API wasnt allowed to be on even Circle Ci.
I have a scenario that requires me to revert to a clean snapshot before or after each Coded UI test method is executed. I have researched using the TFS Lab Management API (see http://blogs.microsoft.co.il/shair/2011/12/22/tfs-api-part-42-getting-started-with-lab-management-api/) to revert to a specific snapshot as part of the TestInitialize and/or TestCleanup method, but I can only get this to work when executed locally. When executed on a remote machine I get errors authenticating to the TFS service.
My other option is to somehow do a 'foreach test in testrun' into the build process template (LabDefaultTemplate.11.xaml). I have identified the area that I think this would fit best, but cannot find any documentation on running a loop on each test.
Is this something that is possible, or is there somehow a built in method to accomplish this that I have overlooked?
To do what you propose you should switch to Release Management and create a separate test run for each of your groupings, in your case each test. You can use RM to orchestrate looping through each of your runs and executing then.
http://nakedalm.com/execute-tests-release-management-visual-studio-2013/
However running a UI test should not break your application and I would suggest that either your tests are way too long, or there is some flaw in the design of your application.