On Tue, Mar 01, 2016 at 05:16:49PM +0100, Martin Vidner wrote:

On Tue, Mar 01, 2016 at 04:53:41PM +0100, Josef Reidinger wrote:

...

Hi, as there is in last days some discussion how rspec can be used as specification or not and I would like to document how bootloader do its proposal, so I take it as oppurinity to write it in RSpec.

Output for better formatting is placed to pastebin http://pastebin.com/raw/8YhuWwVi

Please ignore for now typos. I am more interested if it is readable for you as specification how bootloader is proposed.

Yes, it is a good summary of the requirements!

No, these do not look like requirements but as *one* solution. Requirements should include the motivation. Besides of that, the text does not even mention that it has to do with the "bootloader"; wide context is just missing. And what is "os_prober"? Regards, Arvin -- Arvin Schnell, Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On Wed, Mar 02, 2016 at 11:14:42AM +0100, Josef Reidinger wrote:

On Wed, 2 Mar 2016 11:06:57 +0100 Arvin Schnell wrote:

...

On Tue, Mar 01, 2016 at 05:16:49PM +0100, Martin Vidner wrote:

...

On Tue, Mar 01, 2016 at 04:53:41PM +0100, Josef Reidinger wrote:

...

Hi, as there is in last days some discussion how rspec can be used as specification or not and I would like to document how bootloader do its proposal, so I take it as oppurinity to write it in RSpec.

Output for better formatting is placed to pastebin http://pastebin.com/raw/8YhuWwVi

Please ignore for now typos. I am more interested if it is readable for you as specification how bootloader is proposed.

Yes, it is a good summary of the requirements!

No, these do not look like requirements but as *one* solution. Requirements should include the motivation.

Yes, it is not requirements, it is specification how it works. Requirements and explanation why something is done in given way is captured in comments in code. Specification only say what it do, not why.

I see. As specifications go, RSpec is fairly low level I think. Would it be useful to use something higher level, for example Cucumber? It focuses on descriptions readable by non-programmers which are transformed into code and executed as tests. Here is an example for Zombie Killer: a runnable document (not using Cucumber) - https://github.com/yast/zombie-killer/blob/master/spec/zombie_killer_spec.md and a Cucumber version in the evolved ZK, Rubocop-Yast: - https://github.com/yast/rubocop-yast/tree/master/features (sorry, the examples do involve code because that is the object of the zombie killer) -- Martin Vidner, YaST Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

On Wed, 2 Mar 2016 16:51:01 +0100 Ancor Gonzalez Sosa wrote:

On 03/02/2016 04:41 PM, Martin Vidner wrote:

...

On Wed, Mar 02, 2016 at 11:14:42AM +0100, Josef Reidinger wrote:

...

On Wed, 2 Mar 2016 11:06:57 +0100 Arvin Schnell wrote:

...

On Tue, Mar 01, 2016 at 05:16:49PM +0100, Martin Vidner wrote:

...

On Tue, Mar 01, 2016 at 04:53:41PM +0100, Josef Reidinger wrote:

...

Hi, as there is in last days some discussion how rspec can be used as specification or not and I would like to document how bootloader do its proposal, so I take it as oppurinity to write it in RSpec.

Output for better formatting is placed to pastebin http://pastebin.com/raw/8YhuWwVi

Please ignore for now typos. I am more interested if it is readable for you as specification how bootloader is proposed.

Yes, it is a good summary of the requirements!

No, these do not look like requirements but as *one* solution. Requirements should include the motivation.

Yes, it is not requirements, it is specification how it works. Requirements and explanation why something is done in given way is captured in comments in code. Specification only say what it do, not why.

I see. As specifications go, RSpec is fairly low level I think. Would it be useful to use something higher level, for example Cucumber? It focuses on descriptions readable by non-programmers which are transformed into code and executed as tests.

I tried Cucumber in the past.

I have never found a non-programmer that can read Cucumber. :-)

Moreover, the extra work needed to maintain Cucumber never paid off in the mid-term. We switched to RSpec. Those complaining that RSpec forces the programmer to be more verbose than it should be required will probably simply suicide if exposed to Cucumber. ;-)

Cheers.

PS.- A funny side note, I think the RSpec reference documentation is actually generated using Cucumber. http://www.relishapp.com/rspec/

RSpec use cucumber for its integration testing ;) https://github.com/rspec/rspec-expectations/tree/master/features Otherwise I agree with you regarding cucumber. In long term I found maintaining rspec easier then cucumber and benefits from cucumber almost never appears and rspec output is good for me ( that why I asked on this mailing list if I am alone with that opinion or how others see it ). Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Dne 3.3.2016 v 08:39 Stefan Schubert napsal(a): [...]

I fully agree here. In my former team (SCC) we have used cucumber and I have not really seen the benefits in the daily work. The idea has been that PM should give us the requirements in cucumber format. That has never happend ;-)

Exactly. Cucumber is great when you can get the requirements from outside (PMs, designers, users...) as they can use "English" language. (It's actually not a free form text, it has some keywords and structure so they have to learn it a bit, but it's far more human friendly than RSpec). The problem is that you have to maintain the intermediate part which translates the specification into executable Ruby code. If your tests are too different you need to maintain many transformation rules. Additionaly cucumber is suitable for high level tests as the descriptions are high level. That usually means integration tests, for low level unit tests it's not suitable. And we write mainly unit tests for YaST... Actually the main reason why I switched to cucumber in the rubocop-yast is that cucumber supports multiline arguments in verbatim format [1]. That makes the tests more readable. But this is a specific case as we need to test Ruby code (as string literal) written in Ruby code. Normally you would need to escape all quotes, newlines and that would make it hardly readable... [1] https://github.com/yast/rubocop-yast/blob/master/features/builtins_cop.featu... -- -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 2.3.2016 11:14, Josef Reidinger wrote:

Yes, it is not requirements, it is specification how it works. Requirements and explanation why something is done in given way is captured in comments in code. Specification only say what it do, not why.

I like it as a documentation for "How is it implemented". By reading this, I can easily tell what should I expect on each architecture - I can even see the difference there. Obviously, RSpec does not hold the information WHY is it done so, that would be impossible. For that, we should have comments in code and requirements in README or just somewhere under doc/* Nice example - I'd like to see more of these in our tests! Thanks Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux https://en.wikipedia.org/wiki/Scout_Promise#Czech_Republic http://www.scouting.org/Visitor/WhyScouting/ServingOthers.aspx -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org