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 17:15:42 +0200
  • Message-id: <20180815171542.312a9ec9@linux-vvcf.privatesite>
V Wed, 15 Aug 2018 16:38:02 +0200
Stefan Hundhammer <shundhammer@xxxxxxx> napsáno:

On 15.08.2018 16:08, Josef Reidinger wrote:
Problem with examples is that it stop working and no-one notice it.

This is a myth that I debunked several times already.


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.

With the amount of mocking we typically do in our unit tests, this doesn't
really help very much. That's my point. It only touches the surface.

So maybe we should discuss what is reasonable amount of mocking. I think
similar topic was also described in article that Arvin send about testing.



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.

The expert partitioner can run standalone; that one is not a problem. All the
stuff that is used directly or indirectly by the proposal is a big problem.


So maybe we need to identify why proposal is so big problem? If we can somehow
base proposal on some format that describe conditions on which proposal is
created?



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.

Sorry, no. That byebug debugger is worse than useless. It pretends to offer
something that it doesn't deliver in real life. This is like trying to debug
a complex KDE application with plain gdb - an exercise in futility.

It probably depends what exactly you want to debug. As you can read with it
various internal variables and try to e.g. call propose again to check how it
behave when you modify some condition. But I agree that it is not high level
tool that will allow you to easily modify some installation condition.



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.

Yes, that's what I meant with PITA. I could not imagine anything more
complicated and error-prone and less productive. This is my point.

well, my current workflow with osc:build and dud is exactly what customer doing
in L3 bugs with PTFs, so I would not call it error-prone and complicated. At
least I am not aware about anything better otherwise I believe we will use it
also on customer side.



Kind regards

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

< Previous Next >