V Wed, 15 Aug 2018 15:47:03 +0200 Stefan Hundhammer <[email protected]> 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: [email protected] To contact the owner, e-mail: [email protected]
