In the extremely uncertain environment brought forth by COVID-19, where I had to deal with a lot of personal problems, I am happy to have reached the final stage of my GSoC 2021 journey. This project was a roller-coaster ride in true sense and it taught me way more than just a few clever programming techniques. I am grateful to every community member who came together to make this event possible and successfully so. I am humbled to have had this experience one more time and now let’s dive into all that transpired for me at GSoC 2021.
My meetings with my mentor started when the coding period began. Initially we were meeting (over Zoom calls) twice a week and the first four to five meetings had a singular objective: Making sure that I understood the code-base. This meant that I had to undertake a plethora of tasks to verifiably demonstrate that I had an idea of what was actually going on in the codebase and how all the modular pieces were coming up together as the bddashboard (earlier called dashboard.experiment).
My tasks included:
This project was especially challenging for me as I was attempting to do something that I had never did before and hadn’t really studied it formally. I was not supposed to be coding anything, but testing an already written and functioning code 0_0.
I had always thought of any project in terms of coding deliverables and functionalities. I had never thought of projects in terms of testing, thus it took me a thorough reading of different testing frameworks and methodologies to get accustomed with approaching a project from the perspective of testing. I therefore, ran and re-ran the bddashboard multiple times trying to emulate the behaviors of different perspective users and thinking in terms of user experience and user interface. However, the primary objective was to find breaking points of the app, by putting it through different kinds of datasets and extensively performing all sorts of provided functionalities on the bddashboard in an counter-intuitive order to expedite the process of bringing the breaking functionalities to the surface and fixing it.
Following the process documented in the previous section, the first of my real task was to list as many issues that I could find while using bddashboard. After substantial run-throughs of the bddashboard, I listed 10 issues in the official repository of the project. The issues spanned all domains from better UI to more inclusive UX to breaking features under different permutations and combinations. Many issues were beyond the scope of bddashboard, such as the responsiveness of the Shiny App and the notifications. Other issues related to downloading of the datasets from certain online databases came under the aegis of other projects of bd-R.
Meanwhile, my mentors also pitched in and helped populate the list of issues even further. After the list of issues became quite extensive, I started working on a few issues assigned to me. Thankfully, me and Rahul (one of my mentors) were able to handle almost all the issues within the jurisdiction of bddashboard. Here is the list of PRs, I opened as fixes for the issues raised.
Having gone through several testing methodologies and frameworks, my task was to pick up the tool that will be best suited for the unique testing requirements of our bddashboard. I went through the conference talk on testing by the author of the Golem package, checked out the testing methodologies adopted by well known shiny dasahboards and came across several packages that could be used for testing of Shiny apps to ensure whether they are production ready or not. I conducted research on all testing packages such crrry, puppeteer, gremlins, shinytest etc. but all of them fell short in one way or the other in providing a holistic testing approach for the bddashboard.
Upon the suggestion of my mentors, I started trying out Selenium (RSelenium is the R wrapper of Selenium). RSelenium, at first, felt a little hack-y to almost everyone of us, but we soon realised that it is the best alternative right now for our specific use case. This is because bddashboard is in essence heavily focussed on being the one-stop solution for being the highly extensible dashboard for visualization of all kinds of biodiversity-data. Since the centric aim of our testing was to ensure that all visual elements are producing the desired output or not, the most optimum way to do that was to literally emulate a user session and this would have been best covered by using RSelenium.
After having finally fixated on Selenium, I analyzed the bddashboard the best I could, from a tester’s perspective and came up with 16 modules for testing the dashboard. Between what was critical to be tested and which actually actually tested the functionalities of the dashboard itself and not the functionalities of other packages leveraged in the dashboard, we fixed up on about half of these tests to be written and included in the testing suite of the dashboard. The current status of the project is that a lot of testing modules written in R with the package RSelenium, has been included in the my-testing-suite branch of my forked repository of the bddashboard project. This branch includes, testing suites written for:
With this, I'm happy to report that the initial version of the testing framework of *bddashboard* is for all intents and purposes, a complete project.
We had undertaken quite a challenging task with the testing of bddashboard. As testing this kind of visualization focused Shiny dashboard was mostly without any precedent, according to our research. But, the project right now, is in a happy state with parameterized testthat tests, testing all the critical components of the bddashboard.
The future plans of the bddashboard are mostly up to the mentors to decide, but from my perspective and area of work, I would be aiming to complete/undertake the following tasks
This year’s GSoC was very challenging for me, period. Not only did I have to learn a brand-new testing framework called Selenium and get so adept at it so that I could write a complete testing suite. The process of researching various testing frameworks, libraries and tools and finding the right fit was daunting and challenging for me. Gaining the perspective of a tester was also quite hard for me, but the most challenging and emotionally draining part of this journey for me was to deal with and overcome many personal challenges that came up during the GSoC period, many of which were CoVID induced. I would not dive into the details of what actually happened in my personal life, but it had left me shaken, incapable of functioning, but I’m blessed to have got the support of my parents, relatives, friends and even mentors. They helped me get out of the slump I was in and rise again much stronger than before.
This GSoC had as much life-lessons for me, as it had coding lessons for me. I am just thankful to everyone who supported me throughout this period. Happy to say I’m back at full capacity and feel like a powerhouse. Now, having completed this project, I am ready to tend to it as long as needed and give back to open source and the R Community in general, as much as I can.
Till next time. Peace.