reva VS user_ldap

Before I deep dive into the architecture of what I rebuilt the app during the hackathon, I would like to tell about my experiences in my words. When I first came across #GO Hack Challenge on devpost, I was overwhelming to find related tracks which I could be fit for and tutorials to enrich my knowledge here and there to get into it. It was really a learning opportunity to someone who is newbie and contribute or build any stuff under the hood. I stepped into the open source projects under CERN Foundation, where I didn’t even know what the ecosystem around the project is. I was much curious then. Next, I delved into one of the projects for a few days and looked into a few issues and made a small contribution to it by fixing one of the bugs. I moved to another track where we needed to build any app based on golang. I came to know about use of generic function which is currently released and used in Go >= 18 Version. I managed to rebuild an app using Gin-Gonic framework and use the generic function usage in my app.

The advantage of that above just a simple "these tests are allowed to fail" is that, after adding a feature or fixing a bug, the developer is forced to look into the tests. If tests start to pass, the only job the developer has to do, is to remove them from the expected-to-fail list, and what a joy is that 🎉. From that point on the test has to pass in all future runs, and we are sure not to introduce any regressions. If we would only have an allowed-to-fail list, there would be no pressure to remove tests from that list, humans are humans, so they would forget or miss some. Potentially a bug could get fixed, then see some regression again and none of that would be noticed by the test-suite. So let the computers do what they are good at - automate!

We haven't started to use the API & UI tests from the first day of development, but only after there has been a bare minimum of functionalities implemented in OCIS. To run the tests the first challenge was how to provision the system. The goal is to have feature parity, but of course OCIS did lack a lot of functionality at that stage of development, including APIs to create and delete users, set system relevant settings, etc. Additionally, to run tests in ownCloud X, we heavily rely on the command-line tool to bring the system into a testable state. There is no equivalent (yet) in OCIS. The solution to those challenges was to extend the test-code to do slightly different things on both systems. E.g. OCIS would get users from an LDAP server, in ownCloud X we would provision users and groups through the provisioning api. Luckily we had the LDAP code already in the test-suite from testing the ownCloud LDAP app.