@Dquan said in CSharp -Selenium - MSTEST - Running several methods in the same browser: [ClassCleanup()] Hi again. I have now tested to update the code with [ClassCleanup()]. An now the driver won't start the browser. Also tested to update the start to.[ClassInitialize()]. Any suggestions? Thanks in advance. Kind regards, Fred

If you are only testing the GUI of your application, then it is usually referred to as GUI testing, which is often mistaken with GUI-based system testing. Let's say you have a simple form with fields for first name, last name, address etc. In GUI testing, you would check if, for instance, the layout looks correctly throughout different browser or whether the validation of the form works as expected. GUI-based system testing aims to test the whole system via the GUI. For example, you would verify what the client sends to the server after the submit button is being pressed and how the latter responds. The Galen Framework is an example for GUI testing, whereas Selenium is typically used for GUI-based system testing. Please bear in mind that the exact definition may vary from company to company.

Probably because you close the browser at the end of each test. Which is good because then you test in isolation. But now the session's data is cleaned. Each new Selenium browser starts with a new clean session in order to not influence new test runs with older cookies and such. If you want to re-use the current session, only close/quit the browser at the end of the test suite. You could try to save all the cookies and sessions info after the first test and load them before the next test, but that feels overly complex.

On a single computer you can only install one version of each browser. So to run your Selenium tests against multiple version you will need multiple machines. Easiest: Setup a virtual machine, install browser version of choice (disable automatic updates), install test-runner tools, copy tests to virtual machine and run the tests. Medium: Run you tests against online browsers services, like BrowserStack, SauceLabs or other alternatives. Hardest: Setup a Selenium Grid and configure each virtual machine with unique version numbers. Ask the grid for capabilities so your tests runs can find the correct nodes on the grid. Most time consuming: Removing the browsers version and reinstalling the version you want to test against. Another issue you will have is finding the older versions, but searching for them is possible. Directing you to all older versions is to broad for this question. For the Safari on Mac you might need older version of the operating system as Safari is only shipped with OS-updates. I would recommend using one of the online services if you really need to test and support a broad range of browser versions. Else just support the latest version and add a disclaimer that the users need to upgrade or expect possible issues.

First off, with pen testing you will want to ensure all aspects of your application are tested. This includes authenticated login and non-authenticated login. If you are simply spidering the application to find all the URLs then login and try as that will ensure successful connection to all the URLs. If you are pen testing via spidering and running additional tests on each URL then you will want to do both authenticated and non-authenticated tests to ensure each behaves the way it should. Spring generates things based on the way it's setup and therefore will likely have a bigger structure than what appears to be on the surface. This will likely increase spider time as the spider will reverse engineer the rendered structure to locate all the URL paths that may exist. As the spider finds hidden things it will go down every possible path to locate URLs in the application. This takes time and 10 min. although lengthy, seems reasonable depending on what all is running at the same time via ZAP. URLs must be found, determined viable or not and many checks on these URLs are performed which requires network communication for the handshake checks of each URL. I'm not positive about ZAP settings, but you might be able to adjust some of the settings in the spidering to only check a few things instead of whatever the default settings are. If there are 3 checks on a URL and the handshakes takes 5 sec. now you could be at 15 sec. per URL. Based on what I'm reading in the question there could be a performance improvement task on the application that you might want to look into. It really depends on the specifics though and if the spider is taking a longer time on the spring arch URL setup and not the user facing GUI then that performance hit likely will never affect the user experience. Also, consider running the spider in headless mode to take out the GUI rendering time and speed up the process. If this part makes it alot faster then you might also want to look into boosting performance in your GUI rendering.

Avoid the use of 'Absolute XPath' if possible in your coding. If your element is having with class, ID, name & Type attributes then try to locate the element with the use of Relative XPath. You can use- XPath: //input[@id='portfolioName'] OR XPath: //input[@id='portfolioName'][@type='text'] OR Xpath=//input[@type='text' AND @name='portfolioName[]'] OR Xpath=//input[contains(@id,'portfolioName')] Best & easy way to locate Element with ID attribute is By ID: driver.findElement(By.id("portfolioName"));

I want my tests to fail-fast. A test should never throw an exception. If it does it should break. If one of the first steps fails probably other steps will fail too, generating a lot of unneeded output. You will need to fix the test and run it, so you will find other issues anyways during the fixing. Fail-fast is a programming concept that translates to automated testing pretty well: https://en.m.wikipedia.org/wiki/Fail-fast https://martinfowler.com/ieeeSoftware/failFast.pdf What part of the code need to be modified to stop the execution if click doesnt work because of element not found You need to remove the try/catch. Only use try/catch if you want to handle to exception yourself. You could also add a Assert.fail('your message') in the catch if you want to give a better message to your errors.

First of all, you should definitely avoid storing user credentials in the code repository. What we are currently doing for our test automation setup is: reading user credentials and access keys (in our case, for browserstack) from environment variables when running tests on the Jenkins CI, we are using the Credentials plugin to store credentials and set environment variables appropriately

It is not an ERROR, but INFO it just information shown in the log of the driver. Most loggers have log-levels, INFO is just one you can ignore most of the time: INFO Designates informational messages that highlight the progress of the application at coarse-grained level. https://www.tutorialspoint.com/log4j/log4j_logging_levels.htm The dialect is an internal WebDriver thing you could research it, but I think you should not worry about it.

We log the Jasmine test fails into a text file with a custom reporter. Afterwards we rerun the failed tests again only. If these still fail we report these fails at failures to research. jasmine.getEnv().addReporter({ specDone: async (result) => { if (result.status === 'failed') { fs.appendFileSync(SeleniumBrowser.getFailedTestsFile(), `${result.description}\n`); } await this.quit(); }, }); We use a script to rerun the tests from the command line. We are using jest -T , but with Jasmine I think you can use command-line arguments like --specs='tests/**/*.js' --grep="TestNameFromFile" I once read an article (which I can't find anymore) that the a re-run strategy of three was the perfect number. Sometimes your infrastructure or network just hangs. After three times you are sure it is the test that is failing. I would record the flakiness of these tests though and schedule a flakiness research once in awhile, but you do not want developers to waste adhoc time to re-run or research once in a couple of run errors. Some flaky test do succeed when run alone, these are the tests you do want to fix, but random single incidents should be ignored. keep in mind it could be race-conditions so do check them, but not instant adhoc

Unfortunately you can't do InitElements with a By. As the error indicates, objects initialized using a [FindBy] attribute have to be IWebElement or IList. This means that there are some ExpectedConditions that you will be unable to use with these objects since some ExpectedConditions require a By object. There are a couple of ways around this, and I'm guessing you'll have to make adjustments as needed, since WinDriver probably isn't using IWebElements, but this should hopefully put you on the general right track: For that element, forget about initializing with PageFactory and just use By's with get methods. This way you can get the Element when you want to, but also use the By for some ExpectedConditions Code: protected By CreateBy { get; set; } = By.Name("Create"); //I'm showing IWebElement here, but your Element may be differing with WinDriver protected IWebElement CreateElement() { return excelSession.FindElement(CreateBy); } Keep the [FindBy] using an IWebElement, and create custom Expected conditions for using IWebElement's Code: //Some base method that you can call wherever you need to wait for an element public void WaitForElementToBeClickable(IWebElement element, int timeoutSeconds = 5) { new WebDriverWait(excelSession, TimeSpan.FromSeconds(timeoutSeconds)).Until(d => { try { return element.Displayed && element.Enabled; }catch(NoSuchElementException) { return false; } }); } I've had trouble getting this to work, but you should be able to use a FluentWait instead ignoring the NoSuchElement exception so you don't have to use a try catch.

IMHO, if your UI changes so often that your tests become utterly redundant over a single Sprint - which I am assuming is a 10-15 day period, then the actual issue lies with your UI developers rather than the QA/Testing team. Your UI team should focus on how to minimize the extent of impact of their changes. Completing a project, on time, with good quality, is dependent of the whole team - not just the QA team. If one team is poor in their implementation, then sooner or later, it is going to impact the overall quality of the product delivered. Nevertheless, changing UI - even if it is not that frequent poses difficulties for testers, particularly, who are trying to write automated e2e tests, or tests in general using tools like Selenium, which rely on the underlying HTML for their implementation. Here are a few practises you can follow to minimize the changes that you do in your codebase - Use Page Object Model - There are like hundreds of article on the web regarding how POM can be beneficial when it comes to rapidly changing environments. You can follow the POM principles, which would radically reduce the amount of changes that you need to make in your codebase once changes from frontend are done. Rely on Good Locators - When I say good locators, then I put emphasis on using a lot less of brittle locator - for example absolute xpaths or even Xpaths in general. The good people of SQA community have answered this in a very detailed way here. Implementing these really helps your codebase (I have added these to my framework and it does wonders. Relying Less on UI for Testing - Don’t just utilize the UI for smoke testing if the UI / Application / Workflows change drastically and very often. Most of the time it is also helpful to test certain functionalities by calling WebServices without any Web-UI

In your xpath simply add [1] or [2] or [3] to select the correct one out of the 3 matches. driver.findElements(By.xpath("your locator here)[1]")); This will fetch you the first element with same locator. Like wise driver.findElements(By.xpath("(your locator here)[2]")); will fetch you second element with the same locator driver.findElement(By.id("(element id)[1]"))

A few things to consider come to mind: Only run in Chrome Controversial huh? Let me explain more fully though. My question for multi-browser and indeed multi-device (responsive web sites) testing is always what kind of browser / device specific issues have we seen and do we expect to see? How many browser specific errors have occurred in the last year. That's the first question. frequently the answer is yes but the business demands that we support x,y,z, versions a,b and it means hundreds's of thousands of dollars a year... and before you know it boom everything takes 6 times longer for those combinations... So there is a second piece - blue/green releases. This is the process of being able to release two versions at once. The idea is that you release a small percentage of one version. You can start with 1% and then you monitor that version and the browser breakdown and if you see a browser specific issue you can roll back the new release to 0% and the old release to 100% and then investigate the issue. You'll only have affected a very small number of users, but you know that 100% coverage of every device ever doesn't ever happen either. The key point is not much money loss or customer inconvenience. The reason behind all of this is to speed up development and head towards waiting for minutes for full test runs rather than hours or days and thus enabling continuous integration and continuous delivery. This requires that there be a role for analysts who monitor the staged releases to know when there issues. Sometime you pick a quiet time of the day (depending on market) to do the release to avoid issues with user sessions, cookies, etc. May take a little fiddling here to get it right but I've seen it done. Session adaptation What this means is look into a way that you can get to a particular point in the UI by going directly to that page. Users may need to go through many pages but there are ways to set test sessions to just go to the desired page. With multi form page workflows that can be very significant. One example of this is ruby-rspec-capybara and the rack session gem https://github.com/railsware/rack_session_access Parallelism Not really sure from your answer if you are doing this but you definitely want to use the cheapo power of multiple virtual machines in the cloud to speed up tests. You'll need to make sure the tests are independent from each other which you should be doing, e.g. correct setup and teardown procedures for each test. Run headless There are a couple of flavors here. First is using a headless browser like phantomjs but we've found it only works for some tests, mostly non-js ones. The other (exciting) news here in 2017 is that google has produce a headless version of chrome, now available for download at https://developers.google.com/web/updates/2017/04/headless-chrome I haven't played with it yet. Tag browsers specific tests Tag tests to only run other browser tests for certain functions You may now from experience which pages or areas have historically have multi-browser issues. Based on this knowledge pick out a subset of tests that you want to run in the other browser(s), tag them appropriately and then setup the full suite to use those tags in runs. Get funding dollars Make the case to management for more funding for the vm's and other tools. So the tests take 5 hours. Lets say that means that 4 people have to wait a couple of times week for that. So that is 40 hours in lag time, in other words a full developers time. If a developer costs $70,000 a year, how much should you spend on vm's in comparison ? The fact they are different cost centers on different budgets, blah blah should not be an excuse for doing the right thing for the overall business finances.

As an alternative to feature-based testing, you can also test your SUT based on processes/use cases. Another way is to group coherent test cases into test suites. Then, it's OK to have dependencies between test cases, but test suites should still be independent. However, IMHO, all these things are suboptimal—for all the reasons you've already mentioned. Personally, I prefer virtualization. For instance, Vagrant is an awesome tool for testing; have a look at snapshots: Snapshots record a point-in-time state of a guest machine. You can then quickly restore to this environment. This lets you experiment and try things and quickly restore back to a previous state. Moreover, snapshots are often way faster (and more reliable) than complicated reset scripts. There're also many blog posts on the web regarding the combination of Vagrant and Selenium.