public void selectOptionByPartialText(final String partialText) { WebElement makeElement = driver.findElement(By.id("searchVehiclesMake")); Select makeList = new Select(makeElement); List<WebElement> options = makeList.getOptions(); for (WebElement option : options) { String text = option.getText(); if (text.toLowerCase().contains(partialText.toLowerCase())) { makeList.selectByVisibleText(text); return; } } }

BasePage open() method opens browser window . close() closes browser window HompePage extends from BasePage and has its own open method that adds navigation to the page itself. I will make changes so no base test methods are used, but from my view it does make a little sense

The scope of the Test code which I wrote is basically those 2-3 testcases that were assigned per homework not generalizations

Also, imagine you have 20 test cases which start on some HomePage and end up in Results and there are just a few that end up on DetailsPage . Would you rather have a BaseTest class which handles common steps like opening HomePage or closing browser and have those Homepage->Results tests inherit from it and have Homepage->Results->Details be their own complete classes as exceptions or write each test complete classes thus making future changes lets say to one step in 20 different classes?

1. You took before and after from my BaseTest and rest from one of the tests that extend from it. The reason for these before and after in base so 2 test cases we had are separated into what is common between them ( BaseTest) and different (actual Test classes) and as ResultsPage and HomePage extend from same BasePage then one could call results page.close() or homepage.close() which would have same effect 2. isValidPage() is one of best alternatives to something like hasCorrectPageLoaded() or containsPartialUrl() 3. false in last example you said if one looks at actual method header means is sort order descending or not for comparison I agree my naming is not best

public void fizzBuzz() { for (int i = 1; i <= 50; i++) { String str = ""; if (i % 3 == 0) str += "Fizz"; if (i % 5 == 0) str += "Buzz"; String output = str != "" ? str : String.valueOf(i); System.out.println(output); } }

Should I post my solution? ;)

Yes, I understand when classes are different chaining would make debugging a feat. I am simply going by having Page Elements have their own class like ResultsPage has an object of ResultsFilter class ResultFilter class has object of various filters like MakeFilter, ModelFilter etc and has methods to get directly to those like make Thus call like resultsPage.filters().model().change(model); would be like : Change model selected in ModelFilter which is in Filters of ResultsPage I dont want my tests to know anything about Filters classes ... Something like ResultsFilter filters = resultsPage.filters(); ModelFilter modelFilter = filters.model(); modelFilter.change(model); would need unnecessary imports into Test class in my opinion

No, ResultsPage has object of PageFilters class which has object of ModelFilter class which has change method

As I am never satisfied with my code, I am sure I will change things soon :)

Gotcha, will not bother for now then :)

The method is a composite of multiple methods which achieve one goal - selecting (changing active Model filter value) select() simply finds the model filter element selects it internally withing my WebDriver wrapper class object. I agree , I could try to move the try/catch simply around the attempt to click the element call Regarding recursive methods, yes they do add some complexity, but in this case the recursion only happens on error. I shall move the try/catch to catch only the click attempt

change method selects and changes the option of Model filter in this case. First code is in my ModelFilter page object class and last code is in PageFilter base class that filters inherit common stuff from In test case class the call is : String model = "Mustang"; then its is called like: resultsPage.filters().model().change(model);

I found a slightly better solution. Check for the modal only if you cannot click element: public void change(final String model) { try { select(model); filterMenuNumberResults = getFilterCount(); driver.click(driver.selectedElement()); } catch (WebDriverException e) { checkForModal(); change(model); } } protected void checkForModal() { driver.click(driver.findByClass("acsCloseButton")); } Keep in mind, the driver variable you see in my code is my custom wrapper class for WebDriver and not WebDriver itself

That makes sense. It is just that I have a bit more experience with C# than I do with Java ( last time I did anything Java before the bootcamp was about 6 years ago) and I was thinking of having a C# version of my sample code as well as Java. My Java sample code currently has Maven structure and I am a bit unsure how would I correctly structure a C# project for Selenium if I was to do so. Java packages are a little bit different than namespaces are in .NET for example and closest thing to TestNG in .NET is nUnit I think. I will stick to Java for Selenium for now, but was just wondering if playing around with C# port would be worth the effort

Remember when at the beginning of the training we wrote if-else statements which in case of FALSE did something like System.Exit(0);? With assertions you dont need that, TestNG will take care of everything for you :) Assertions are basically your booleans, just that assertions are TestNG (and probably other test frameworks) validation syntax shortcuts. I go by these rules of thumb: Use assertions only in your Test Case classes Use if-else or if needbe switch-case statements in your page object model and framework classes

Don't you mean If-Else statements vs Assertions?

No problem, basically the test would fail as the survey popup blocks direct clicking the page elements until its closed. I also have a boolean setup that is set to TRUE once the popup is detected and closed so when I check for popup before next filter selection I check for that boolean and if it is still FALSE then check for popup if not then just continue

I check for it (close button for survey is of class acsCloseButton) before changing each Filter eg. check for it before Selecting Model then check before selecting Year

The way I remember is that variables and methods are camelCases, classes and interfaces are PascalCases