Coverage with Travis and Coveralls

[mvidner]

I took what @lslezak had in yast-registration end extended the yast stubs a bit. The results are

• https://travis-ci.org/mvidner/yast-cio
• https://coveralls.io/r/mvidner/yast-cio

(currently set up against my fork, but once this is merged I will delete that and replace it with the yast/yast-cio repo)

[mvidner]

I am not sure about the best way to stub YaST SCR and UI. I used plain class and def which is most likely wrong in RSpec. Also note that RSpec 3 and 2.99 fails when it sees Object.any_instance.stub.

[lslezak]

SLES runs on 2.1, 2.0 is not needed.

[jreidinger]

Well, I think that this approach is not nice as it mock a lot of stuff that need to be synced. For me better approach is to have it in ruby-bindings, where ruby bindings can be gem and C part can be dependency, that can be replaced by mock.

[mvidner]

Mocking: yes, it should go to a common package, probably ruby-bindings. It should become a gem so that Travis can fetch it. Before we start doing that, could we agree on how it is going to work and leave that library piggybacked in this package? You know, incremental steps.

[mvidner]

Ruby versions: I have checked that SLE12 has 2.1.2. For the record, openSUSE 13.1 has 1.9.3 and 2.0.0 but we don't care about backporting this, do we? I will also add ruby-head, allowed to fail, as a lookout for the bleeding edge. See also http://rubies.travis-ci.org/

[lslezak]

I think the current state is good enough. The mocking is not ideal, but Travis integration is a nice feature, worth of doing some workarounds IMHO...

[mvidner]

BTW if we get this out of the way then I will add https://github.com/mvidner/yast-cio/tree/unban-spec and https://github.com/mvidner/yast-cio/tree/ui-objects ;-)

[jreidinger]

@mvidner well, I think we need to start to make everything gem to make things easier on travis. I do not want to mock also stuff from yast2.rpm or other dependencies.

[mvidner]

@jreidinger so what do we do with this one?

• merge
• merge after branching sle
• fix a, b, c
• ...

Note that "make everything a gem" is a rather large task which I don't want to depend on. Perhaps "write proper mocks here, then move them to yast2.rpm"?

[jreidinger]

@mvidner - my problem is still same. I do not like yast_stubs as for me it is example of overmocking, where you need to mock even basic shared functionality. And to be honest I do not know how to easy fix it. What is possible is to specify for travis only some tests, that do not have dependency on yast framework ( so no dialogs, only tests for channels classes )

[lslezak]

I'm currently working on a better solution for Travis support - I'm preparing Yast packages for Ubuntu so they can be installed in Travis nodes. With this approach we do not need any mocking, Yast will be present in the build system.

This will also enable running the old Yast testsuites or even C++ agents or perl/ruby bindings can be tested (if they have a testsuite, if not at least a compile/install check can be done).

I'd suggest to close this PR and wait for the better solution which is BTW my Hackweek project 😉. (GitHub says I do not have write permissions to close it, huh???)

[jreidinger]

OK, lets close it.

[jreidinger]

@lslezak I forgot to add yast-classic team so you do not have permissions there, but now it is fixed.

[lslezak]

@jreidinger ok, thanks!