SoK/2023/StatusReport/Rishi Kumar: Difference between revisions

Revision as of 20:46, 12 April 2023

Accessibility: Work on improving the accessibility of Tokodon

This project aims to improve the accessibility of tokodon by writing appium tests.

Writing these tests would ensure a set standard of code quality is maintained in tokodon and with improved accessibility leading to a more efficient and convenient experience for the end users.

Mentor

Carl Schwan

Merge Request

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 whether the status was a normal status or containing 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, which led Tokodon to stop building due to some build and dependencies error, so the subsequent weeks was spent on fixing various errors which I tackled by comparing the work/sok/offline-tokodon branch with the master branch and with previous commits, 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

Once all the build errors were fixed and Tokodon was able to build successfully, I worked on adding tests for testing different types of media attachments on statuses, for which I referred to Mastodon’s documentation to see what response is received while requesting different kinds of media attachment, which I then integrated into the already present statuses.json file, after which I was successful in displaying different kinds of media attachment.

Once all the different types of media attachments were visible, I expanded the TimelineTest test to include testing of media attachments by asserting whether the different types of media attachments were visible. The merge request for the implementation 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 managed to write 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.

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.

@@ Line 32: / Line 32: @@
 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 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]
+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 ===