On Thu, Jul 31, 2014 at 10:33:02AM +0200, Josef Reidinger wrote:

> In this case it is not so easy, but there is ways.
> E.g. one of possible ways is to write test as part of change, then
> refactor as you are more brave to do it.
> There is also parts which is very hard to test as it have many
> side-effects or keep states. I think in such situation you can do
> minimal modification to make it more testable, write test that proves
> it and then refactor it more deeply. e.g. in this pull request -
> https://github.com/yast/yast-bootloader/pull/127 I at first modify
> changeOrderInDeviceMapping to not modify directly @device_mapping, but
> have it as parameter, write tests for it and then add functionality I
> need with additional tests. In general any change that improve
> isolation of method greatly helps with testing of it.
> Another think I am trying to do, is to break it more in earlier phases
> ( like when I implement features as my impression is that each feature
> contain at least one bug :), so I made bigger changes and were more
> brave, writed tests for it and when some regressions apeared, then I
> improve tests to prevent it and also can refactor more aggressive this
> new code when it is needed.

I could also give examples where I refactored something during
feature development but I can also give examples where it did not
work:

- Last year I tried to make some dialog in yast2-storage object
  oriented. As discussed on this list with the strange ruby mixin
  a major rewrite would have been required.

- One bug requests a small partition (within the size of
  cylinders). Since YaST calculates in cylinders this is
  problematic. Changes will require modification to various
  modules (e.g. libstorage, yast2-storage, yast2-bootloader,
  likely also AutoYaST). Didn't happen due to no time at all - at
  least on my side.

So I still have not seen a reasonable concept how to improve the
situation with YaST.

One thing I consider a requirement are automated integration test
as discussed before. But half a year later still no progress.

Regards,
  Arvin

-- 
Arvin Schnell, <[email protected]>
Senior Software Engineer, Research & Development
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 
16746 (AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
-- 
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]

Reply via email to