I created a test suite that has 57 different tests in it for one of my environments. Now, I would like to implement the test suite to 10 other nearly identical environments. I have already done a dry run in the second environment and it runs well, the issue is that I need to go through and manually change the base url for each individual test every time I open the suite.
Ideally, Id like to have "Environment 1 test suite", "Environment 2 test suite", etc. When I click on a test suite, it opens the tests with the base url for the corresponding environment. I tried saving the modified suite. I tried saving the individual copies of the test cases. I cant figure out how to get the new copy of test cases to stop reverting to the original base url when I close and reopen the suite.
You should use a properties file. Provide the URL in a variable and then use this variable to set the Base URL in your scripts.
To add a properties file, create a text file such as TestData.js containing your base URL:
baseUrl="http://www.boogiesite.com"
Now add this file to Selenium IDE using IDE > Options > Options > General tab > Selenium IDE Extensions > browse and select file TestData.js.
Reference:
http://selftechy.com/2011/06/30/parameterization-of-tests-in-selenium-ide
A similar previous SO question provides more answers:
selenium IDE - how can I change the Base URL for all my tests in one go
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.
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
Is there a way to overwrite a value contained within a config.properties file via Jenkins?
I have the following config.properties file contained within my automation framework:
browser=chrome
url=http//www.example.com
If the value of chrome get changed to firefox then all tests will now execute within firefox browser.
I can manually change this value by directly accessing the config.properties file but can the value get altered via jenkins?
I use the Pipeline Utility Steps plugin to read properties files, and it looks like it can write a few other types of files, but not properties files.
It seems to me that you want to make this change in this file so you can run some tests first in one browser, then in another. If this is the case, I think a better way to handle this is to try to get your tests to point to different files. This is a little cleaner, and allows things like parallel execution and when you find that another thing needs to change in the future, you won't be writing so many things to the file in a script, which gets a little error prone.
If you can't make your tests execute against a different properties file, you could have a copy of each file you need, and then copy them to them appropriate filename to execute your tests.
But maybe I made poor assumptions as to your setup here. ;)
Yes.
You can create a build parameter as $browser to accept the value say "firefox" and using sed inside "execute shell", replace the value in config.properties.
Once done, execute your scripts.
This is just overview as you have not posted details about your config.properties file, its location, if you are using Jenkins jobs or jenkinsfile/pipeline etc.
I am using VSTS to maintain our test cases.
I have created a test suite named Login Tests inside test plan foundation, which contains all the scenarios for login validation.
I want to add all existing test cases which are in Login Tests to my new test plan. Currently, I am manually copying and pasting the IDs in the search query,but is there any way where I can get all the test cases inside a suite.
No, there is no way to do as you describe.
However there is an easy workflow change that will allow you to do this. You have some manual work to get there, but once there things will be better. You should go through all of your Test Cases in the manual Suite and tag them with "tests-login".
Once done you can easily create Query Based suites anywhere with the correct list and control the list using the Tag.
Right Click the suit in the VSTS Test manager folder and Export to email you can select multiple suit and past in excel from email
Is there a way to mark a fitnesse test such that it will not be run as part of a suite, but it can still be run manually?
We have our FitNesse tests running as part of our continuous integration, so new tests that are not yet implemented cause the build to fail. We'd like a way to allow our testers and BAs to be able to add new tests that will fail while still continuing to validate the existing tests as part of continuous integration.
Any suggestions?
The best way to do this is with suite tags. You can mark tests with a tag from the properties page and then you can filter for the or filter to exclude them.
In this case I would exclude with "NotOnCI" tag. Then add the following argument to the URL:
ExcludeSuiteFilter=NotOnCI
This might look like this then as the full URL:
Http://localhost:8080/FrontPage?test&ExcludeSuiteFilter=NotOnCI
You can select multiple tags by splitting with commas, but they act as "or",Not "and".
Check the FitNesse user guide for more details. http://fitnesse.org/FitNesse.UserGuide.TestSuites.TagsAndFilters
Would it make sense to have multiple Suites, one for regression tests that should always pass, and another one for the tests that are not yet implemented?
Testers and BAs can add tests/suites to the latter suite and the CI server only runs tests in the former suite.
Once a developer believes he has implemented the behavior they can move the test/suite relating to that functionality to the 'regression' suite so that it will be checked in continuous integration.
This might make the status of a test/suite a bit more explicit/obvious than just having a tag. It would also provide a clear handover from development to test/BA to indicate the implementation is finished.
If you just want to have a test/suite not run during an overall run of a suite that contains the particular test/suite you could also just tick 'Skip (Recursive)' in the properties page of that test/suite (below 'Page Type').