Introduction

Firstly the information about the tools has been shared that which tools would be used basically and following tools are shown:

• Selenium
• Python
• Pytest
• openpyxl
• Reports (HTML, Allure)
• pytest-xdist (Parallel execution)

The selenium and python tools are used default as for testing. The pytest has been also covered in previous lectures. The openpyxl is being used for data driven testing. The reports would be used for some of the reports that start with HTML and allow reports. The parallel execution would also be done with the help of module pytest-xdist for parallel execution.

As selenium python and pytest lectures have been done in previous videos so these tools have already been installed. As python selenium with python has been learnt and pytest as well. So other modules will also be installed in sequence as the lecture progresses.

So now as we have been doing pytest and pytest cases that have syntax to follow so in the lecture it is given the name as demo tc. The first that has to be done is refactor it and name it as:

test_searchflights.py

The test_ is added because of requirement of a particular test case to be recognized as a test case in point. The class name and method name would also be changed as follows:

class TestSearchAndVerifyFilter ( ):

def test_search_flights(self)

As the class name has been changed so a new object will be created on its basis and variable will be placed that holds the reference of that particular object as follows:

dauto = TestSearchAndVerifyFilter ( )

dauto . test-search_flights ( )

The next bit is to externalize the driver launch basically browser launch and maximizing the page so opening the application and particular website will be maximized in the window. 

driver = webdriver.Chrome(executable_path=ChromeDriverManager ( ) ,install ( ))

wait = WebDriverWait (driver, 10)

driver.get(https://www.yatra.com/)

driver .maximize_window

As the working is done in the pytest and in pytest tutorial there is a conf test file that has been learnt already. So that file would be utilized for the setup and tear down methods. So simply a new python file and it would be named as “conftest.pyfile” and the method would be created in this file and added the above setup in the new file to initiate the test. Some errors would be removed from it and imported the selenium webdriver and also the chrome manager would be imported here. The test would now be named as:

@pytest.fixture(scope=”class”)

def setup ( ):

driver = webdriver.Chrome(executable_path=ChromeDriverManager ( ) ,install ( ))

wait = WebDriverWait (driver, 10)

driver.get(“https://www.yatra.com/”)

driver .maximize_window ( )

As a part of pytest series it has been learnt that if the fixture scope has to be defined at the class level, the fixture can simply be added as scope and it could also be called simply as class. In order to call this particular setup fixture at class level simply the setup name is needed to get. In test_search_flights which is the test class simply it would be said as pytest and a decorator marker is already known so it would be named as:

@pytest.mark.usefixtures(“setup”)

Fixing the Errors

As the browser has to be launched and open the test URL and maximize the window which is common for the test cases. To remove the errors simply the pytest would be used in the particular class to remove it. 

There would be a couple of more errors as well so wait and then proceeding towards driver. As the launching browser has been removed so previously it was being done with webdriver.chrome and then the particular driver would be instantiating as the driver variable was holding the particular driver to drive the browser instance. That browser instance is no more part of this test class. 

In order to setup the teardown there was a keywords known as yield and anything that you put after the keyword yield was the teardown method. So as for example if the driver needs to be closed so the command would simply be given as follows:

yield

driver.close ( )

Teardown

So driver.close ( ) is the teardown and explained as part of the pytest that would be easily understood through series as it is important to understand the framework.

Now the first things is that whatever driver instance is present that needs to be recognized so basically the driver instance has to be recognized in this particular file in the test file. So basically it is the method that instantiates the driver. Now unless until the driver is passed or the driver drives the methods that are therein this specific file, there is no linkage between contest  and the test file.

Request Fixture

In order to provide the linkage what pytest provides us would be known through the pytest documentation for better understanding. So there is shown a request fixture that is available in pytest as well. It is a special fixture that provides information of the requesting test function. The test function needs driver from this particular fixture so the request fixture can be used that is the special fixture provided by pytest and it could be provided as part of set up as:

request.cls.driver = _driver

Once the driver is instantiated as part of the process it is said that the particular driver or reference should now be available at the class level of the requesting class. In this test the test.search is calling the setup fixture now the driver should be available to that particular calling fixture and the cls in the request stands for class.

If the documentation is read on the website it would be seen that the usage basically shows cls that means class and it can be none where the test function was collected. So now the driver should be available here and the last bit here in order to fix these errors. As it has been understood as part of python series as well that if class variables are called right so the (self) command as:

def test_search_flights (self):

So wherever in the command the errors are shown with the wait simple the self.wait command would be helpful in mitigating the error. After all this discussion the approach comes out to be:

@pytest.mark.usefixtures(“setup”)

def setup(request) :

driver = webdriver.Chrome(executable_path=ChromeDriverManager ( ) ,install ( ))

wait = WebDriverWait (driver, 10)

driver.get(“https://www.yatra.com/”)

driver .maximize_window ( )

request.cls.driver = _driver

yield

driver.close ( )

In the whole command the self would be added with the driver and wait in order to eradicate the error issues in the code. The browser launch and the application launch have been externalized and launched as they were part of the setup fixture. 

So for running another test case it would simply be required to call @pytest.mark.usefixtures(“setup”) fixture and launching browser and opening the driver website or opening the application URL will be handled automatically. So whole the approach lines will not be required to write again as it has been done previously for running any other test case. 

Running the Pytest

The next thing comes to run the pytest so for this simply the configurations will be opened simply on the software and the configuration of pytest would be added here. For this we will select the script and go to the test cases select the test and ok to apply the test. Now it can be interpreted that in the configuration in the pycharm we have pytest in test search. Now if we run it and the result will be shown as it has launched the browser and opened website and maximized the page and fail. So this was expected thing.

The reason of its failure is that if we analyze the results there is attribute error that has no attribute wait in the test object. This is obvious that it would fail. 

The request fixture is the special fixture that we are using in the test in order to return the driver object that got created here as part of the setup but webdriver.wait is also being used but we are not passing that to our test case. So here self.wait would be added and it has to be transformed from setup(request) to request.cls.driver = driver which is the test class driver. So the new command would be as:

request.cls.wait = wait

The wait variable here holds the reference of the particular webdriver which is being used in the test case. That reference is being assigned to the class so there is a chaining basically for the driver as well as the wait. So now if we go back and run the test case again then it would work as expected. It should open the browser, open the driver website and whatever test case was doing previously. 

There will occur a synchronization issue along with other issues that need to be fixed time to time. As part of this framework development we will fix all of these issues and it would be actually done in different projects as well. 

So now after removing those issues again the test is run in order to know that it would simply run this time. It would also be known that if the test case would pass the keys so that the keys do not get passed so quickly that the test case fails all together. 

So after running the case it would be shown that the test has been passed and no changes have occurred in the script and it has clocked on the search flight and it will wait for the whole page to scroll and this what dynamic scroll is called. So it would show that the JavaScript executor is being used here in the particular page. It has shown that the test has failed again which was expected because of the assertion errors. 

The four steps in the test case are not completed and the last step is not able to find its stop in one of the locators as shown below: 

The text is: 1 Stop

assert pass

The text is: 1 Stop

assert pass

The text is: 1 Stop

assert pass

The text is: 1 Stop

assert pass

The text is: 

So either it is a locator issue or the actual text itself is not getting being extracted from the locator which shows that there is one stop and it is not able to finalize the that assertion.