SoK/2023/StatusReport/Rishi Kumar: Difference between revisions
| (24 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
This project aims to improve the accessibility of tokodon by writing appium tests. | This project aims to improve the accessibility of tokodon by writing appium tests. | ||
By writing these tests, we can ensure a set standard of code quality is maintained in Tokodon, resulting in improved accessibility and a more efficient and convenient experience for end-users. | |||
== Mentor == | == Mentor == | ||
| Line 10: | Line 10: | ||
== Merge Request == | == Merge Request == | ||
* [https://invent.kde.org/network/tokodon/-/merge_requests/190 Merge Request for testing different types of media attachments in statuses]. | |||
* [https://invent.kde.org/network/tokodon/-/merge_requests/189 Merge Request for fixing build errors after rebase]. | |||
* [https://invent.kde.org/network/tokodon/-/merge_requests/176 Merge Request for testing different types of interactions on status and its type]. | * [https://invent.kde.org/network/tokodon/-/merge_requests/176 Merge Request for testing different types of interactions on status and its type]. | ||
* [https://invent.kde.org/network/tokodon/-/merge_requests/168 Merge Request for testing Search] | * [https://invent.kde.org/network/tokodon/-/merge_requests/168 Merge Request for testing Search] | ||
| Line 24: | Line 26: | ||
=== Week 1 and Week 2 === | === Week 1 and Week 2 === | ||
I spent the first two weeks researching how I would start tokodon without network connectivity. I achieved this by creating a new entry point called main-offline.cpp with the account initialised as the object of MockAccount class. After this, I created an executable named tokodon-offline by making relevant changes in src/CMakeLists.txt. The merge request for the implementation can be found [https://invent.kde.org/network/tokodon/-/merge_requests/154 here]. | |||
=== Week 3 and Week 4 === | === Week 3 and Week 4 === | ||
I spent the following two weeks writing an Appium test for the search functionality in tokodon-offline. To achieve this, I first had to fix the broken search functionality in tokodon-offline, I achieved this by studying the already written unit-tests for search. After analysing the code, I found that mock API calls were made to receive search results through a search-result.json file. I followed the same approach and made the same mock API calls to receive search responses, which helped me in fixing the search functionlity. The merge request for this implementation can be found [https://invent.kde.org/network/tokodon/-/merge_requests/155 here] | |||
Once the search functionality was implemented, my next task was to write | Once the search functionality was implemented, my next task was to write Appium test for it, for which I referred to [https://planet.kde.org/harald-sitter-2022-12-14-selenium-at-spi-gui-testing/ Harald's blog] for the implementation. The merge request for search appium test can be found [https://invent.kde.org/network/tokodon/-/merge_requests/168 here] | ||
=== Week 5 and Week 6 === | === Week 5 and Week 6 === | ||
The CI pipelines of tokodon were failing due to the tests performing settings read/write operations which were not required while testing | The CI pipelines of tokodon were failing due to the tests performing settings read/write operations which were not required while testing. The maintainers of Tokodon helped me identify this issue and made a commit to fix the issue [https://invent.kde.org/network/tokodon/-/commit/78504f9784398b0815571024dfacc81ca25eaac0 here]. | ||
After the CI pipelines were fixed I worked on writing appium tests for testing the interaction buttons of status and whether the status was a normal status or | After the CI pipelines were fixed I worked on writing appium tests for testing the interaction buttons of status and testing whether the status was a normal status or contained a spoiler text. For achieving this I first made mock API calls to fetch the required statuses on the main timeline. Then wrote appium tests for the relevant interactions button and type of status. The final merge request for the implementation can be found [https://invent.kde.org/network/tokodon/-/merge_requests/176 here] | ||
I also wrote a mid-journey [https://k3yss.github.io/posts/sok_blog1/ blog post] about my Season of KDE experience in these weeks | I also wrote a mid-journey [https://k3yss.github.io/posts/sok_blog1/ blog post] about my Season of KDE experience in these weeks | ||
=== Week 7 and Week 8 === | === Week 7 and Week 8 === | ||
My mentor Carl Schwan helped me rebase work/sok/offline-tokodon to the latest master so that I could work on the latest changes in tokodon-offline. However, after rebasing, Tokodon stopped building due to some build and dependencies error. Therefore, the subsequent weeks were spent on fixing various errors. To fix these errors, I compared the work/sok/offline-tokodon branch with the master branch and with previous commits. During this time, Carl was always available to give me clues whenever I felt stuck while fixing these errors. The merge request for fixing the build errors can be found [https://invent.kde.org/network/tokodon/-/merge_requests/189 here]. | |||
=== Week 9 and Week 10 === | === Week 9 and Week 10 === | ||
After successfully fixing all the build errors and ensuring that Tokodon was able to build successfully, I worked on adding tests for testing different types of media attachments on statuses. To achieve this, I referred to Mastodon's documentation to understand what response is received while requesting different kinds of media attachments, which I then integrated into the already present statuses.json file. This helped me in displaying different kinds of media attachments successfully. | |||
Once all the different types of media attachments were visible, I expanded the TimelineTest test to include testing of media attachments. This was done by asserting whether the different types of media attachments were visible. I have submitted a merge request for the implementation which can be found [https://invent.kde.org/network/tokodon/-/merge_requests/190 here]. | |||
=== Week 11 and Week 12 === | === Week 11 and Week 12 === | ||
The final weeks were spent reviewing the commits and making final changes. Following which I wrote my second [https://k3yss.github.io/posts/sok_blog2/ blog post] about my SoK experience. | |||
== Conclusion == | == Conclusion == | ||
In conclusion, I have written 2 appium tests containing 8 sub-tests for testing various functionalities and improving the accessibility of Tokodon's GUI, which required making 6 Merge Requests. | |||
I am very grateful to my amazing mentor, Carl Schwan, for giving me the opportunity to work on Tokodon. He has always been incredibly patient with my queries and has provided meaningful and helpful feedback on my contributions. Despite his busy schedule, he has made time to attend meetings with me to offer guidance and discuss the progress of my project. He even went out of his way to help me write my blog and gave his insightful opinions and comments on my status report. | |||
I would also like to express my gratitude to: | |||
* Nmariusp for his incredible [https://www.youtube.com/@nmariusp videos] and one-on-one sessions on Matrix, which helped me get started as a KDE contributor in the first place. | |||
* Harald Sitter for his incredible [https://invent.kde.org/network/tokodon/-/merge_requests/190 AT-SPI-based Webdriver], which made this project possible in the first place. I also want to thank him for reviewing my Merge Requests and being understanding when I had silly doubts. | |||
* Redstrate for his reviews on my Merge Requests and guidance whenever I felt stuck. | |||
* The wonderful KDE community for their wonderful aura and positivity. | |||
== Beyound SoK == | |||
During the SoK, I learnt a lot about how development takes place inside KDE and I plan continue contributing to KDE as much as I can in future | |||
== Contact == | |||
I am on Matrix as @k3ys:matrix.org. | |||
Latest revision as of 06:07, 14 April 2023
Accessibility: Work on improving the accessibility of Tokodon
This project aims to improve the accessibility of tokodon by writing appium tests.
By writing these tests, we can ensure a set standard of code quality is maintained in Tokodon, resulting in improved accessibility and a more efficient and convenient experience for end-users.
Mentor
Carl Schwan
Merge Request
- Merge Request for testing different types of media attachments in statuses.
- Merge Request for fixing build errors after rebase.
- Merge Request for testing different types of interactions on status and its type.
- Merge Request for testing Search
- Merge Request for fixing the broken search UI in tokodon-offline
- Merge Request for making tokodon-offline executable.
Blog Posts
Timeline
Week 1 and Week 2
I spent the first two weeks researching how I would start tokodon without network connectivity. I achieved this by creating a new entry point called main-offline.cpp with the account initialised as the object of MockAccount class. After this, I created an executable named tokodon-offline by making relevant changes in src/CMakeLists.txt. The merge request for the implementation can be found here.
Week 3 and Week 4
I spent the following two weeks writing an Appium test for the search functionality in tokodon-offline. To achieve this, I first had to fix the broken search functionality in tokodon-offline, I achieved this by studying the already written unit-tests for search. After analysing the code, I found that mock API calls were made to receive search results through a search-result.json file. I followed the same approach and made the same mock API calls to receive search responses, which helped me in fixing the search functionlity. The merge request for this implementation can be found here
Once the search functionality was implemented, my next task was to write Appium test for it, for which I referred to Harald's blog for the implementation. The merge request for search appium test can be found here
Week 5 and Week 6
The CI pipelines of tokodon were failing due to the tests performing settings read/write operations which were not required while testing. The maintainers of Tokodon helped me identify this issue and made a commit to fix the issue here.
After the CI pipelines were fixed I worked on writing appium tests for testing the interaction buttons of status and testing whether the status was a normal status or contained a spoiler text. For achieving this I first made mock API calls to fetch the required statuses on the main timeline. Then wrote appium tests for the relevant interactions button and type of status. The final merge request for the implementation can be found here
I also wrote a mid-journey blog post about my Season of KDE experience in these weeks
Week 7 and Week 8
My mentor Carl Schwan helped me rebase work/sok/offline-tokodon to the latest master so that I could work on the latest changes in tokodon-offline. However, after rebasing, Tokodon stopped building due to some build and dependencies error. Therefore, the subsequent weeks were spent on fixing various errors. To fix these errors, I compared the work/sok/offline-tokodon branch with the master branch and with previous commits. During this time, Carl was always available to give me clues whenever I felt stuck while fixing these errors. The merge request for fixing the build errors can be found here.
Week 9 and Week 10
After successfully fixing all the build errors and ensuring that Tokodon was able to build successfully, I worked on adding tests for testing different types of media attachments on statuses. To achieve this, I referred to Mastodon's documentation to understand what response is received while requesting different kinds of media attachments, which I then integrated into the already present statuses.json file. This helped me in displaying different kinds of media attachments successfully.
Once all the different types of media attachments were visible, I expanded the TimelineTest test to include testing of media attachments. This was done by asserting whether the different types of media attachments were visible. I have submitted a merge request for the implementation which can be found here.
Week 11 and Week 12
The final weeks were spent reviewing the commits and making final changes. Following which I wrote my second blog post about my SoK experience.
Conclusion
In conclusion, I have written 2 appium tests containing 8 sub-tests for testing various functionalities and improving the accessibility of Tokodon's GUI, which required making 6 Merge Requests.
I am very grateful to my amazing mentor, Carl Schwan, for giving me the opportunity to work on Tokodon. He has always been incredibly patient with my queries and has provided meaningful and helpful feedback on my contributions. Despite his busy schedule, he has made time to attend meetings with me to offer guidance and discuss the progress of my project. He even went out of his way to help me write my blog and gave his insightful opinions and comments on my status report.
I would also like to express my gratitude to:
- Nmariusp for his incredible videos and one-on-one sessions on Matrix, which helped me get started as a KDE contributor in the first place.
- Harald Sitter for his incredible AT-SPI-based Webdriver, which made this project possible in the first place. I also want to thank him for reviewing my Merge Requests and being understanding when I had silly doubts.
- Redstrate for his reviews on my Merge Requests and guidance whenever I felt stuck.
- The wonderful KDE community for their wonderful aura and positivity.
Beyound SoK
During the SoK, I learnt a lot about how development takes place inside KDE and I plan continue contributing to KDE as much as I can in future
Contact
I am on Matrix as @k3ys:matrix.org.