Hello, Am Freitag, 14. August 2015 schrieb Lukas Ocilka:

This might be understood as quite a controversial theme, but that's actually the reason why I'm writing it here.

I've seen the progress in our last sprint and most of our delaying was caused by "trying to implement" some openQA test. This means we are fixing half of bugs we could.

As I see it, there are two ways of step over this problem:

1. Minimize creating openQA tests to a.) features b.) important issues that are likely to break in the future [short to mid term]

I'd argue that "issues" are missing or broken features, so a) is always true ;-)

2. Make creating openQA tests a piece of cake, maybe by introducing some Yast library, maybe by contributing to openQA to make it well understandable, well documented [mid to long term]

We'll be, most probably, required to fix more bugs in Leap and SLE 12 SP1 in the near future. For that reason, I'd prefer #1 now, switching to #2 later.

Is there any #3 or #4? Or maybe I'm just looking at it through different optics - maybe you even feel the bugfixing flow fast enough?

3. change 2. to "short to mid term" or, even better, "short term" ;-) This means you'll "loose" some days to get started with openQA and to develop something that makes writing tests easier. I can already hear someone saying "we have no time for that" - but I'm quite sure you'll save that time while writing tests within some months. BTW: The interesting question might be if you always need to use openQA or if the YaST-internal testsuite is a better choice in some cases. Feel free to s/openQA/testsuite/ whenever it fits. I know it's easy to say for me because I'm not involved in YaST programming ;-) We had a similar situation with tests for the AppArmor tools, and I learned the hard way that investing time to create test infrastructure is _always_ a good idea because it made it much easier and faster to write the tests. (BTW: the AppArmor 2.9 aa-* tools had a test coverage of 18%, 2.10 has 36% :-) Oh, and I probably don't need to tell you that rewriting code is much easier and faster with a good test coverage - at least I'm less afraid of breaking something if the tests still pass ;-) Regards, Christian Boltz -- No trees were killed in the sending of this message. However a large number of electrons were terribly inconvenienced. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Hello, Am Freitag, 14. August 2015 schrieb Lukas Ocilka:

This might be understood as quite a controversial theme, but that's actually the reason why I'm writing it here.

I've seen the progress in our last sprint and most of our delaying was caused by "trying to implement" some openQA test. This means we are fixing half of bugs we could.

As I see it, there are two ways of step over this problem:

1. Minimize creating openQA tests to a.) features b.) important issues that are likely to break in the future [short to mid term]

I'd argue that "issues" are missing or broken features, so a) is always true ;-)

2. Make creating openQA tests a piece of cake, maybe by introducing some Yast library, maybe by contributing to openQA to make it well understandable, well documented [mid to long term]

We'll be, most probably, required to fix more bugs in Leap and SLE 12 SP1 in the near future. For that reason, I'd prefer #1 now, switching to #2 later.

Is there any #3 or #4? Or maybe I'm just looking at it through different optics - maybe you even feel the bugfixing flow fast enough?

3. change 2. to "short to mid term" or, even better, "short term" ;-) This means you'll "loose" some days to get started with openQA and to develop something that makes writing tests easier. I can already hear someone saying "we have no time for that" - but I'm quite sure you'll save that time while writing tests within some months. BTW: The interesting question might be if you always need to use openQA or if the YaST-internal testsuite is a better choice in some cases. Feel free to s/openQA/testsuite/ whenever it fits. I know it's easy to say for me because I'm not involved in YaST programming ;-) We had a similar situation with tests for the AppArmor tools, and I learned the hard way that investing time to create test infrastructure is _always_ a good idea because it made it much easier and faster to write the tests. (BTW: the AppArmor 2.9 aa-* tools had a test coverage of 18%, 2.10 has 36% :-) Oh, and I probably don't need to tell you that rewriting code is much easier and faster with a good test coverage - at least I'm less afraid of breaking something if the tests still pass ;-) Regards, Christian Boltz -- No trees were killed in the sending of this message. However a large number of electrons were terribly inconvenienced. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org