Final Report- Wikimedia Foundation

Shailesh Kanojiya
6 min readAug 23, 2021

--

Introduction

The Project Wikimedia Preview provides a preview that pops up while hovering or clicking over it such that the definition or meaning of the words can be shown. This is made for the third-party usage so that Wikimedia can provide such features to the users. My role was to develop a set of test cases that need to be ran before any build happens. This is helpful when a new feature or an enhancement is brought up then it needs to be checked on certain boundaries and constraint.

The goal of the project is to enhance the working of Wikipedia-Preview by testing the preview against test cases. This involves writing a quality level of tests that checks the preview on different parameters. This will help in identifying the fallback conditions and help in delivering better Preview to the end users.

Task Performed

The work carried out is categorized in the manner such that the following test case were developed.

Creation of the Page Object

The page object of the Preview that pop-up on hovering is created. Page objects are necessary to access the different components through class objects. This helps to keep the code clean and improve its readability. This way we can access the elements in more

This involved creating a class such that all the elements/object/html container will behave as in object of that class. This can be achieved by Page Object Model. One way is to consider the Html page as a Tree and follow the parent element to point the child element. Other way is to directly pinpoint the element using an id or unique attribute.

One of key factor in testing is to define the element independently such that it doesn’t need to be dependent on the existence of the parent elements. This is achieved in the latter way.

We can use selectors by using the Tree Model or by using a combination of find and get methods of cypress. But both methods pose a problem of slow accessibility of elements and there might be a chance of renaming the parent element from the frontend side which will fail our test and needs to undergo many changes to fix it. Thereby, it is preferred to use get method and a data attribute which makes it more selective to access the elements.

Layout Testing

The aim of creating this test is to check for the visibility and appearance of all the layouts depending on the content being accessed. All the layouts are shown here. This involves understanding the different layout and the classes being attached to it during the runtime.

The test is achieved by mocking the content/changing the content specific to a layout such that the Html elements specific to a layout can be test based on its visibility and appearance.

The above test was committed on the following PR.

API Testing

The aim of this test is to checks the preview based on the content it receives from the API. The Layout is based on the images, content size, content availability, network status.

The test is developed by mocking the API content such that it receives the content as per our requirement and the test checks that it creates the specific layout based on the content it received. It further on checks the preview visibility and existence of elements. Later on, this test was discarded by mentors as it doesn’t benefit the purpose of creating test cases.

The above test was committed on the following PR.

Active Testing

The aim is to test the popping up of preview. The Preview pop-up appears either by hovering over the content or icon or by clicking over the content. The pop-up disappears on clicking the close button.

The test was developed by mocking the clicking on the element. In the similar manner, the hovering of element was developed. Testing the appearance and closing the preview by clicking on the close button confirms the test.

The above test was committed on the following PR.

Offline Testing

The aim of this test is make sure that the app in offline mode behave in a similar manner as it is in online mode. The method were explored where we can make it offline during the test and note their behavior in offline mode. Here is the link. Those commands were implemented in our application to create a test for offline mode.

Custom Commands

These commands were defined in the page object. These commands include the set of rules to test elements based on its visibility and appearance. These commands were used in each of the test to make sure the existence of the elements.

Layout Mobile Testing

The aim of this test is to check the working of the preview when opened or viewed in Mobile. This aims to check the different layout in the mobile mode.

For the following test, I explored the Cypress Mobile Commands. These commands are helpful in conducting the testing for mobile versions. It has commands for visiting mobile-specific sites, commands for making directional-specific swiping such that users can make multiple directional swiping on the screen. In this way, users can initiate various swiping and we can mock those swiping using the mobile commands. Tests have been created to make those swiping events.

The above test was committed on the following PR.

Expand Mode Testing

The aim is to test a specific to the expanded layout of Wikipedia preview. This require the users to click on the Continue Reading button to visit the expanded mode.

The test is developed by mocking the click and making the preview to enter the expanded mode and then check the visibility and existence of elements using custom commands.

The above test was committed on the following PR.

Page Movement Testing

One of the important tests is the Page Movement. This is divided into subparts:

· Firstly, a test that checks the Read More part of the Wikipedia Preview. When one clicks on the Read More div, then it should take the user to the content/definition page. This is done by changing the value of the target attribute of the <a> tag element and making it equal to ‘_self’. This helps to test the newly visited page in the same window.

· Lastly, test the reload of the page. This test opens the preview and then reloads the page. Once the page reopens, we again click on the preview and check for its existence.

The above test was committed on the following PR.

Gallery Testing

· The major part of the project, i.e. to create a test for the Gallery Section of the Preview. The development of the test starts by creating the page object of the Gallery Section. The gallery page object will be used in the creation of test cases and helps in accessing the elements easily.

The test cases for Gallery is divided into two subparts:

· First test is to check the opening of the gallery section. This involves clicking on the gallery part of the preview and opening the Gallery.

· Second test is to check the switching of the images on the Gallery. This is carried by the clicking of the previous and Next buttons provided in the Gallery

The Test cases are designed to test the Gallery for the mobile version. These are as follow:

· Created a Test to check the opening of the gallery section in mobile view

· Designed test to check the switching of the images in Gallery by swiping the images.

· Lastly, a test was designed for checking the scrollable part of the caption provided in some images. This check

The above test was committed on the following PR.

Mobile Swipe Testing

The test is divided into two major part:

· Firstly, a test to check the scroll ability of gallery images. The gallery images were shown in the preview, are scrollable. So, the test involved mocking the scroll effect. This is achieved by swiping the gallery images using mobile commands.

· Lastly, a test developed to check the scroll ability of the caption present within the images inside the gallery section. The test is designed to mock the scroll effect to confirm that the text in caption can be scrolled.

The above test was committed on the following PR.

Configuring .YML file

This involved refactoring the .YML such that the set of rules is defined for the build. This will help to predict the build of test cases.

Conclusion

I learned a lot about mobile testing and code readability. Similar way, while adding the custom functions as methods in Page Objects, I learned about the code understanding and re-usability. The whole project taught me the area of testing and things to be kept in mind while development. As far as cypress is concerned, I learned a lot newer ways and figured out different ways to carry out the testing. In the end, it all summed out to be a great experience.

--

--

Shailesh Kanojiya
Shailesh Kanojiya

Written by Shailesh Kanojiya

Software Developer and Undregrad at IIT Kharargpur

No responses yet