V Wed, 15 Aug 2018 16:38:02 +0200 Stefan Hundhammer <shundhammer@suse.de> 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@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org