Test Cases

[nephros]

Hello all,

I have just pushed the branch test-cases: https://github.com/sailfishos-patches/patchmanager/tree/test-cases

It contains a little qml app, a qml plugin, and two patches.

One patch is for 32-bit, one for 64-bit.
Both patches change the files in the qml plugin dir.
The app shows whether either patch has been applied.

All of those are packaged into an extra RPM, patchmanager-test-cases.

These can for now be used to test the 32bit/64bit mangling, with the goal to extend to other tests over time.

I don´t really want to make a PR so not to clutter to the sources.
IMO this can live in a separate branch just fine, but if you want it merged, we can do that too.

[nephros]

Added a third patch, which possibly points to a bug in the mangling detection code:

32-to-64 uses the following style of diff file:
    --- a/usr/lib/foo
    +++ b/usr/lib/foo

32-to-64-alt uses the following style of diff file:
    --- /usr/lib/foo
    +++ /usr/lib/foo

both are equally valid inputs for patch -p1 -d /, but the released version of the mangling code probably only detects one of those versions.

[Olf0]

Preferred to write the comment for this at the corresponding PR #237 (comment).

[Olf0]

WRT the original topic of this "discussion", the test-cases:

I like them, thank you!

What I do not really like are just two formal issues:

• The top level directory is currently named test (singular), but IMO should be called tests (plural) or test-cases (personally I prefer the simpler tests).
• The tests currently reside in a separate branch, which is fine if the aim is to merge it. As I currently cannot provide much more feedback on this topic, and Vlad seems to be even more severely lacking time, I suggest to rename the top level directory and create a PR to merge the branch into the master branch without further ado.
  Keeping the tests in a separate branch reduces their visibility a lot, hence IMO that does not make much sense.

[nephros]

Alright, I have moved the files into a subdir of tests called patching, with the rationale that code unit tests or somesuch may be in another subdir of tests/ at some point.

PR incoming ;)

[Olf0]

→ PR #258