Mailinglist Archive: yast-devel (36 mails)

< Previous Next >
Re: [yast-devel] Executing our own code: inst-sys clients
  • From: Josef Reidinger <jreidinger@xxxxxxx>
  • Date: Wed, 15 Aug 2018 16:08:41 +0200
  • Message-id: <20180815160841.06cba8d4@linux-vvcf.privatesite>
V Wed, 15 Aug 2018 15:47:03 +0200
Stefan Hundhammer <shundhammer@xxxxxxx> napsáno:

While working on a bug related to the partitions_proposal client of
y-storage-ng, I wondered why we don't have a simple way to call our own code.

I want to be able to start the stuff that I work on in my normal work
environment.

I was told that "it just takes 4-5 lines of Ruby code", but that's not a
useful answer; why don't we have a ready-made wrapper for those things if
it's really so simple? I have no clue what I need to set up first before I
can call that thing programatically. I need to see it in connection with the
proposal because that's what it's used for.

We have a lot of infrastructure already in place:

- For storage scenarios, we have YAML files describing the existing disk
setup; we use them in the unit tests.

- We have control XML files for all our products.

- We have a lot of AutoYaST files that we use for automated tests.

- We have an examples/ subdirectory in y-storage-ng, but that doesn't contain
much.


It's a PITA to start a real installation and then modify the inst-sys with
bind-mounts and whatnot, always copying files to that inst-sys after each
change.

The easier we make it to call our code directly, the more it will be done
which means much more thorough (manual!) testing, and the easier it will be
to develop on that code.

Automated testing can only go so far; unit tests use a lot of mocking and
assumptions, and OpenQA is limited in the number of scenarios that can
reasonably be tested, and it isn't helpful for us during development: I need
to see what I am doing, I can't wait for half a week for a test result, and I
don't want to check in code that I never saw running (which for Ruby
typically means that there will be one crash for every 3 lines of code
written).


So, for simple things I propose we get into the habit of providing a simple
example that can easily be called. Back when I wrote the UI, I did that for
every single widget, and even in different degrees of difficulty and
complexity: PushButton1.rb, PushButton2.rb, ...

Hi HuHa,
I think you open interesting topic as insts-sys is a bit limited and sometimes
set it up is not trivial. So let me try to answer some of your question ( not
sure if it is what you want to read :)

Problem with examples is that it stop working and no-one notice it. So for me
examples is great if it comes with automatic validation. But I agree that for
UI it makes a lot of sense to verify that it looks as it should.

This encourages people to execute the code, to see how it behaves, how it is
supposed to be used, and to do some first level of testing. I don't know
about you guys, but I cannot develop without that. Rspec and unit testing
have limits, even more so with the arcane error messages that Rspec throws at
you when you do anything wrong.

Well, for me it really depends which part of code I develop. If it is backend,
public API or something low level then rspec is great. For UI I prefer examples
which I can manually run. This is e.g. reason why for expert partitioner we had
(or still have ) special client that can work with passed yaml file.


How can we get there? Don't you have the same problems? How do you develop
code that will live in the inst-sys?

well, integrated byebug debugger helps. But my usual workflow is to write code,
write tests that verify it works as expected. Then I call rake osc:build and
via dud I try to run installation with modified code to be sure I do not
overlook anything. I do not say it is perfect, but usually works fine for me,
just it can be faster. What I did in past was also usage of /y2update, but I
often forget to copy back my manual modification of installation sources.


I suggest we set up a Jangouts call to discuss this.

make sense for me. just finding good time will be hard.

Josef



Kind regards

--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References