Change Details

===Profile Information **Name**: Bello Gbadebo **Email**: gbahdeybohbello@gmail.com **IRC nick**: Gbahdeyboh **Resume**: [Download Resume](https://res.cloudinary.com/gbahdeyboh/image/upload/v1582899872/Gbadebo_Bello_CV_G_wndlzb.pdf) **Location**: Lagos, Nigeria **Typical working hours**: Between 6pm and 2am WAT(UTC+01:00) ===Synopsis Wikimedia has a couple of projects which are being tested from time to time either via Jenkins or as a part of Continuous Integration on each check-in to Gerrit, some of this tests are completely automated using a browser automation framework, WikiMedia currently uses a test automation framework built atop of WebdriverIO and selenium for their testing their repositories. WebdriverIO allows you to run tests based on web driver protocols. While this is a great tool, there are useful alternatives which provide certain features that either WebdriverIO does not have at all, or has a less efficient implementation of which are also easier to set up and work with. This, therefore, makes it important to consider switching to other alternatives. Currently, there are two most probable alternatives that could be switched to which are Puppeteer and Cypress. Puppeteer is a high-level browser automation API built atop Chrome DevTools Protocols while Cypress is a Front end End to End testing framework. {F31708123} The chart above shows a comparison between the usage of Puppeteer, Cypress, and WebdriverIO. This chart automatically shows us that Puppeteer and Cypress are good alternatives for WebdriverIO. I aim to extensively evaluate the usage of both Puppeteer and Cypress by deeply Integrating both of them with some of Wikimedia's repositories. The evaluation process would take into consideration several factors that would help determine which is the best alternative for WebdriverIO and how much work would be required to switch all repositories to the selected tool. This proposal proposes the use of puppeteer, a high-level browser automation API built atop Chrome DevTools Protocols. This makes it a very flexible tool as you don't have to install and configure a separate browser driver to run tests, Chrome DevTools protocol is also compatible with other browsers asides chrome. The following are some of the Cons WebdriverIO; ##### Difficult to Setup Webdriver is difficult to set up, the current implementation of WebdriverIO requires the installation of a separate browser driver for the specific browser the test is to be run with as well as separately installing Webdriver itself. Unlike tools like puppeteer and Cypress that can be installed using one line of code. ##### Difficult to upgrade When a new version of WebdriverIO is released, it's always a difficult process to migrate to a new version of it. ##### Device Emulation Puppeteer and Cypress allows the emulation of several mobile devices, including tablets, androids, and iPhones. Puppeteer and Cypress handles device emulation differently from WebdriverIO. With WebdriverIO, you simply resize the screen of the webpage to that of the device you want to emulate. There are a couple of problems with this implementation, some of the functionality of the webpage might be dependent on the device OS and not necessarily it's screen size, In such a scenario, Webdriver IO would handle device emulated tests poorly. ##### Access to Chrome Dev Tools Puppeteer and Cypress by default has full access and control over all of the chrome Devtools functionality which makes it very useful when writing tests, It's gives access to functionalities like Network throttling, code coverage, browser's console, etc. However, WebdriverIO needs to use Puppeteer under the hood to access chrome dev tools. ##### Simpler JavaScript Execution Puppeteer makes it very easy to run JavaScript codes within the browser or current page context. This feature is super useful and comes in handy when testing. **Mentor(s)**: @zeljkofilipin , @Jpita Have you contacted your mentor already? Yes, I have already contacted them. ===Deliverables - Getting familiar with all the tests codebase of some Wikimedia projects I'll be working on. - Working with mentors to define what needs to be tested on each project. - Re-writing automated tests for some of the Wikimedia projects I'll be working on as a part of the evaluation. - Providing a well-detailed documentation for these tests. - Working with mentors to define standards for the tests. - Working with mentors to deploy these tests to various platforms i.e Jenkins, CI/CD, etc. - Giving the Pros and Cons of each framework this test was written in #### Phase I evaluation - Understand the workflow of MediaWiki and run manual tests on it. - Identify what needs to be tested and new tests that need to be added that wasn't previously implemented with WebdiverIO Describe the timeline of your work with deadlines and milestones, broken down week by week. Make sure to include the time you are planning to allocate for investigation, coding, deploying, testing and documentation ===Participation * I will be online on Zulip during my working hours ( 6:00 pm to 2:00 pm WAT(UTC+1)). * I will use Phabricator for managing bugs. * I will be easily reachable via my Gmail during my non-working hours. * I will publish my weekly reports as a task on phabricator. * All my codes would be pushed to a new branch on gerrit. ===About Me I'm currently in my 3rd year, B.Tech Electrical and Electronics Engineering at the Federal University of Agriculture, Abeokuta. I got to hear about GSoC from a friend and saw a project that interests me on Wikimedia's Project Ideas page. I'm currently eligible to participate in GSoC and I believe the program would help me kick-start my career in Open Source Development I'm a very enthusiastic person, and I'm usually very excited when learning something new or improving on something I previously knew. I've had some past experience with puppeteer, I feel with this project, I could improve my automation testing skills and write code that actually gets used by a lot of people ===Past Experience - I wrote a crawler that scrapes similar data off of 8 different websites, wrangles and correlates this data and serves the data over a RESTful API - I contributed to the Open Collective API and fixed an issue they had with Rounding monetary amounts [here](https://github.com/opencollective/opencollective-api/pull/2392) - I built a simple tool that does a deep comparison of Objects in JavaScript [here]() #### Micro Tasks Completed - https://phabricator.wikimedia.org/T248016 - https://phabricator.wikimedia.org/T248232 - https://phabricator.wikimedia.org/T248219 (Commit [here](https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/584079/))

===Profile Information **Name**: Bello Gbadebo **Email**: gbahdeybohbello@gmail.com **IRC nick**: Gbahdeyboh **Resume**: [Download Resume](https://res.cloudinary.com/gbahdeyboh/image/upload/v1582899872/Gbadebo_Bello_CV_G_wndlzb.pdf) **Location**: Lagos, Nigeria **Typical working hours**: Between 6pm and 2am WAT(UTC+01:00) ===Synopsis Wikimedia has a couple of projects which are being tested from time to time either via Jenkins or as a part of Continuous Integration on each check-in to Gerrit, some of this tests are completely automated using a browser automation framework, WikiMedia currently uses a test automation framework built atop of WebdriverIO and selenium for their testing their repositories. WebdriverIO allows you to run tests based on web driver protocols. While this is a great tool, there are useful alternatives which provide certain features that either WebdriverIO does not have at all, or has a less efficient implementation of which are also easier to set up and work with. This, therefore, makes it important to consider switching to other alternatives. Currently, there are two most probable alternatives that could be switched to which are Puppeteer and Cypress. Puppeteer is a high-level browser automation API built atop Chrome DevTools Protocols while Cypress is a Front end End to End testing framework. {F31708123} The chart above shows a comparison between the usage of Puppeteer, Cypress, and WebdriverIO. This chart automatically shows us that Puppeteer and Cypress are good alternatives for WebdriverIO. I aim to extensively evaluate the usage of both Puppeteer and Cypress by deeply Integrating both of them with some of Wikimedia's repositories. The evaluation process would take into consideration several factors that would help determine which is the best alternative for WebdriverIO and how much work would be required to switch all repositories to the selected tool. This proposal proposes the use of puppeteer, a high-level browser automation API built atop Chrome DevTools Protocols. This makes it a very flexible tool as you don't have to install and configure a separate browser driver to run tests, Chrome DevTools protocol is also compatible with other browsers asides chrome. The following are some of the Cons WebdriverIO; ##### Difficult to Setup Webdriver is difficult to set up, the current implementation of WebdriverIO requires the installation of a separate browser driver for the specific browser the test is to be run with as well as separately installing Webdriver itself. Unlike tools like puppeteer and Cypress that can be installed using one line of code. ##### Difficult to upgrade When a new version of WebdriverIO is released, it's always a difficult process to migrate to a new version of it. ##### Device Emulation Puppeteer and Cypress allows the emulation of several mobile devices, including tablets, androids, and iPhones. Puppeteer and Cypress handles device emulation differently from WebdriverIO. With WebdriverIO, you simply resize the screen of the webpage to that of the device you want to emulate. There are a couple of problems with this implementation, some of the functionality of the webpage might be dependent on the device OS and not necessarily it's screen size, In such a scenario, Webdriver IO would handle device emulated tests poorly. ##### Access to Chrome Dev Tools Puppeteer and Cypress by default has full access and control over all of the chrome Devtools functionality which makes it very useful when writing tests, It's gives access to functionalities like Network throttling, code coverage, browser's console, etc. However, WebdriverIO needs to use Puppeteer under the hood to access chrome dev tools. ##### Simpler JavaScript Execution Puppeteer makes it very easy to run JavaScript codes within the browser or current page context. This feature is super useful and comes in handy when testing. **Mentor(s)**: @zeljkofilipin , @Jpita Have you contacted your mentor already? Yes, I have already contacted them. ===Deliverables - Getting familiar with all the tests codebase of some Wikimedia projects I'll be working on. - Working with mentors to define what needs to be tested on each project. - Re-writing automated tests for some of the Wikimedia projects I'll be working on as a part of the evaluation. - Providing a well-detailed documentation for these tests. - Working with mentors to define standards for the tests. - Working with mentors to deploy these tests to various platforms i.e Jenkins, CI/CD, etc. - Giving the Pros and Cons of each framework this test was written in #### Phase I evaluation - Understand the workflow of MediaWiki and run manual tests on it. - Identify what needs to be tested and new tests that need to be added that wasn't previously implemented with WebdiverIO Describe the timeline of your work with deadlines and milestones, broken down week by week. Make sure to include the time you are planning to allocate for investigation, coding, deploying, testing and documentation ===Participation * I will be online on Zulip during my working hours ( 6:00 pm to 2:00 pm WAT(UTC+1)). * I will use Phabricator for managing bugs. * I will be easily reachable via my Gmail during my non-working hours. * I will publish my weekly reports as a task on phabricator. * All my codes would be pushed to a new branch on gerrit. ===About Me I'm currently in my 3rd year, B.Tech Electrical and Electronics Engineering at the Federal University of Agriculture, Abeokuta. I got to hear about GSoC from a friend and saw a project that interests me on Wikimedia's Project Ideas page. I'm currently eligible to participate in GSoC and I believe the program would help me kick-start my career in Open Source Development I'm a very enthusiastic person, and I'm usually very excited when learning something new or improving on something I previously knew. I've had some past experience with puppeteer, I feel with this project, I could improve my automation testing skills and write code that actually gets used by a lot of people ===Past Experience - I wrote a crawler that scrapes similar data off of 8 different websites, wrangles and correlates this data and serves the data over a RESTful API - I contributed to the Open Collective API and fixed an issue they had with Rounding monetary amounts [here](https://github.com/opencollective/opencollective-api/pull/2392) - I built a simple tool that does a deep comparison of Objects in JavaScript [here]() #### Micro Tasks Completed - T248016 - T248232 - T248219 ([[ https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/584079/ | 584079 ]])

===Profile Information **Name**: Bello Gbadebo **Email**: gbahdeybohbello@gmail.com **IRC nick**: Gbahdeyboh **Resume**: [Download Resume](https://res.cloudinary.com/gbahdeyboh/image/upload/v1582899872/Gbadebo_Bello_CV_G_wndlzb.pdf) **Location**: Lagos, Nigeria **Typical working hours**: Between 6pm and 2am WAT(UTC+01:00) ===Synopsis Wikimedia has a couple of projects which are being tested from time to time either via Jenkins or as a part of Continuous Integration on each check-in to Gerrit, some of this tests are completely automated using a browser automation framework, WikiMedia currently uses a test automation framework built atop of WebdriverIO and selenium for their testing their repositories. WebdriverIO allows you to run tests based on web driver protocols. While this is a great tool, there are useful alternatives which provide certain features that either WebdriverIO does not have at all, or has a less efficient implementation of which are also easier to set up and work with. This, therefore, makes it important to consider switching to other alternatives. Currently, there are two most probable alternatives that could be switched to which are Puppeteer and Cypress. Puppeteer is a high-level browser automation API built atop Chrome DevTools Protocols while Cypress is a Front end End to End testing framework. {F31708123} The chart above shows a comparison between the usage of Puppeteer, Cypress, and WebdriverIO. This chart automatically shows us that Puppeteer and Cypress are good alternatives for WebdriverIO. I aim to extensively evaluate the usage of both Puppeteer and Cypress by deeply Integrating both of them with some of Wikimedia's repositories. The evaluation process would take into consideration several factors that would help determine which is the best alternative for WebdriverIO and how much work would be required to switch all repositories to the selected tool. This proposal proposes the use of puppeteer, a high-level browser automation API built atop Chrome DevTools Protocols. This makes it a very flexible tool as you don't have to install and configure a separate browser driver to run tests, Chrome DevTools protocol is also compatible with other browsers asides chrome. The following are some of the Cons WebdriverIO; ##### Difficult to Setup Webdriver is difficult to set up, the current implementation of WebdriverIO requires the installation of a separate browser driver for the specific browser the test is to be run with as well as separately installing Webdriver itself. Unlike tools like puppeteer and Cypress that can be installed using one line of code. ##### Difficult to upgrade When a new version of WebdriverIO is released, it's always a difficult process to migrate to a new version of it. ##### Device Emulation Puppeteer and Cypress allows the emulation of several mobile devices, including tablets, androids, and iPhones. Puppeteer and Cypress handles device emulation differently from WebdriverIO. With WebdriverIO, you simply resize the screen of the webpage to that of the device you want to emulate. There are a couple of problems with this implementation, some of the functionality of the webpage might be dependent on the device OS and not necessarily it's screen size, In such a scenario, Webdriver IO would handle device emulated tests poorly. ##### Access to Chrome Dev Tools Puppeteer and Cypress by default has full access and control over all of the chrome Devtools functionality which makes it very useful when writing tests, It's gives access to functionalities like Network throttling, code coverage, browser's console, etc. However, WebdriverIO needs to use Puppeteer under the hood to access chrome dev tools. ##### Simpler JavaScript Execution Puppeteer makes it very easy to run JavaScript codes within the browser or current page context. This feature is super useful and comes in handy when testing. **Mentor(s)**: @zeljkofilipin , @Jpita Have you contacted your mentor already? Yes, I have already contacted them. ===Deliverables - Getting familiar with all the tests codebase of some Wikimedia projects I'll be working on. - Working with mentors to define what needs to be tested on each project. - Re-writing automated tests for some of the Wikimedia projects I'll be working on as a part of the evaluation. - Providing a well-detailed documentation for these tests. - Working with mentors to define standards for the tests. - Working with mentors to deploy these tests to various platforms i.e Jenkins, CI/CD, etc. - Giving the Pros and Cons of each framework this test was written in #### Phase I evaluation - Understand the workflow of MediaWiki and run manual tests on it. - Identify what needs to be tested and new tests that need to be added that wasn't previously implemented with WebdiverIO Describe the timeline of your work with deadlines and milestones, broken down week by week. Make sure to include the time you are planning to allocate for investigation, coding, deploying, testing and documentation ===Participation * I will be online on Zulip during my working hours ( 6:00 pm to 2:00 pm WAT(UTC+1)). * I will use Phabricator for managing bugs. * I will be easily reachable via my Gmail during my non-working hours. * I will publish my weekly reports as a task on phabricator. * All my codes would be pushed to a new branch on gerrit. ===About Me I'm currently in my 3rd year, B.Tech Electrical and Electronics Engineering at the Federal University of Agriculture, Abeokuta. I got to hear about GSoC from a friend and saw a project that interests me on Wikimedia's Project Ideas page. I'm currently eligible to participate in GSoC and I believe the program would help me kick-start my career in Open Source Development I'm a very enthusiastic person, and I'm usually very excited when learning something new or improving on something I previously knew. I've had some past experience with puppeteer, I feel with this project, I could improve my automation testing skills and write code that actually gets used by a lot of people ===Past Experience - I wrote a crawler that scrapes similar data off of 8 different websites, wrangles and correlates this data and serves the data over a RESTful API - I contributed to the Open Collective API and fixed an issue they had with Rounding monetary amounts [here](https://github.com/opencollective/opencollective-api/pull/2392) - I built a simple tool that does a deep comparison of Objects in JavaScript [here]() #### Micro Tasks Completed - https://phabricator.wikimedia.org/T248016 - https://phabricator.wikimedia.org/T248232 - https://phabricator.wikimedia.org/- T248219 (Commit [here](([[ https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/584079/) | 584079 ]])