Testing improvements

[pabloyoyoista]

Since #31 there are some basics tests which should help with development. However, the test process and the code is certainly improvable. This issue aims to document the most obvious problems for future reference:

• The tests wrap Glib tests into python unittests, just because it was the easiest to setup. This should be changed to just a python script that starts the dbus mock server, runs tests and stops it.
• The simple DBusMock implementation is too simple with just an AddMethods call, which allows to do very little (for example, no error testing possible). This should be changed to independent functions which implement each of the DBus methods.
• The tests only consider successful DBus calls, but never any errors.
• gs_plugin_refine is not tested, and probably one of the most important ones for a well-looking application. For those tests, it might be a good idea to set external-appstream-urls to have some real-world apps downloaded.
• It would be ideal to also test behavior of appstream::source-file during refine. See Refine fixes #35

[Cogitri]

gs_plugin_refine is not tested, and probably one of the most important ones for a well-looking application. For those tests, it might be a good idea to set external-appstream-urls to have some real-world apps downloaded.

Yeah, but it's also the toughest one to test. We probably want test to not require an internet connection, if possible. And we have lots of side effects in that function too when AS decides to refine the package already.

[pabloyoyoista]

Yeah, but it's also the toughest one to test

Yes, definitely... Although being able to manually set the refine flags in the jobs helps.

We probably want test to not require an internet connection, if possible.

Well, I guess we can just fetch one of the Components files that appstream-generator produces, trim it to just have a couple of useful apps, and drop it in the repo. That would avoid using the external-appstream-urls

And we have lots of side effects in that function too when AS decides to refine the package already.

Maybe we have different approaches here or maybe I am misunderstanding it, but isn't this what we ideally want? The apk plugin can provide very little information about the apps (mostly installation status and version/updatable version). So in my mind, our refine should just take care of becoming the manager plugin for the apps created by AS and set installation status, version and the other little metadata we can provide. I managed to move forward one WIP branch taking care about this yesterday, so I just pushed to #35 if you want to assess if it fixes some of the side-effects you were thinking of.

[pabloyoyoista]

The refine is indeed now being tested through the other calls. No major regressions in a while.