Hi Freifunk and GSoC communities!
This first month on GSoC where totally exciting! Toghether with my mentors we faced a lot of challenges implementing the unit testing for elRepo.io. In the following lines I’m going to describe all the work done!
Milestones acomplished:
– Refactor of retroshare-dart-wrapper to be more testeable and implement null-safety to it.
https://gitlab.com/andrearuizrull/retroshare-wrapper-dart/-/merge_requests/1
– Implement null-safety for elRepo-lib.
https://gitlab.com/andrearuizrull/elrepo-lib/-/merge_requests/1
– Implement null-safety for elRepo-android
https://gitlab.com/andrearuizrull/elRepo.io-android/-/merge_requests/1
– Start developing unit tests
https://gitlab.com/andrearuizrull/elRepo.io-android/-/blob/feature/unit_testing/test/ui/
Narrated step by step progress
First steps, obviously, where familiarize myself with elRepo.io stack, the libraries, making my Flutter environment working, compiling elRepo.io for first time… The interaction with my mentors where key for this steps, deciding what libraries to use for testing.
Once I started to develop tests on this branch we realized that, for Dart language, static and top level functions where not easily mockable, my mentors suggest me to do a refactor of the retroshare-wrapper was needed in order to make the tests because we had to mock the API calls.
So we designed a new wrapper, trying to bring compatibility with the other pieces of the elRepo.io. We used Dart http.client as inspiration to create the new RsClient and we implemented it.
This refactor constrained us to upgrade Dart minimum SDK version and migrate all the code to null-safety, which, subsequently, made us to upgrade Dart SDK and migrate to null-safety all the other projects.
On the way, we solved some “Todo’s” on the code and fixed a few bugs. And write some simple tests to check that with the refactor, the API calls can be mocked as we need.
After this big refactor we manually tested the app until everything works properly and it have no more null safety errors.
Finally, I started to write unit tests for elRepo-android, starting from the login screen, and magically, first test passed!
But tests are a whole world and I had to study how to test stuff like the Navigator, how to don’t test platform related tests (which should be tested on the integration tests), I learned how to mock classes using generated code, or how to mock the providers etc…
A lot of interesting stuff! 🤓
Some thoughts
This first phase bring me some conclusions or ideas I would like to share.
The test for the login success history where very difficult to implement for me: a lot of API calls made, with a lot of spaghetti code: a function on elRepo-android call a function on elRepo-lib that call a function on the retroshare-dart-wrapper. All this architecture is needed for the app, but some questions rised:
– If we mock only the API calls, tests are larger and more difficult to implement, but it also tests elrepo-lib and the retroshare-dart-wrapper.
– elRepo-lib is still using top level functions, which are not mockable. To mock elrepo-lib directly could boost our test implementations on the app side, but it need a big refactor, i have to discuss with my menthors if this is prioritary now.
– This difficult-to-test-histories are flags that point where the code could be improved and splitted. This will improve performance, scalability and maintainability.
Now, I’m waiting next meeting with my mentors for instructions to push forward the development.