On Thu, 31 Jul 2014 11:07:51 +0200
Arvin Schnell <aschnell(a)suse.de> wrote:
On Thu, Jul 31, 2014 at 10:33:02AM +0200, Josef
In this case it is not so easy, but there is
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
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
- 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.
I agree that for some parts it is more tricky then for others. In
general more coupled
code tent to be hard to change and also test isolated.
One possible strategy how to deal with it, is find the least coupled
part and move it out, as it should be relative easy and decrease
coupling of remaining modules depending on it.
Some articles with hints how to decrease coupling:
(quite nice one and with named parameters, it can look even better)
( especially this one really show some problems of YaST )
- 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.
Well, this is not refactoring, but design change. I worry, there is no
easy way to change it if all modules takes it as axiom. What you can do
to prevent it in future is abstraction which allows easy change of
underlaying units. In fact e.g. bootloader usually do not care if sizes
are in cylinders or bytes, only in very specific cases when there is
limit in bootloader itself.
So I still have not seen a reasonable concept how to improve the
situation with YaST.
I hope we will discuss it on workshop with conclusion what metrics we
will use and what need modified code fulfill ( e.g. if we have metrics
and marks, then we can say, if you touch this file or method, then
final file or method must have B grade in feature phase, C in Beta
phase and D in RC phase ). There is already some discussions about it
on this mailing list, so I thing we just need to decide what we will
One thing I consider a requirement are automated integration test
as discussed before. But half a year later still no progress.
There is some, we have at least autoyast tests in openqa.suse.de. Of
course we can do more, but at least we start with it.
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org