On Thu, 31 Jul 2014 10:21:35 +0200 Arvin Schnell <[email protected]> wrote:
> On Wed, Jul 30, 2014 at 03:32:50PM +0200, Josef Reidinger wrote: > > > I found this nice article[1] that nicely and visible summarize all > > my arguments why refactoring should not be separated tasks, but > > integral part of all work. I think it deserve reading. > > In general I agree with the article but it doesn't apply to YaST > since we already have years of backlog for refactoring. So for us > making it correct does not take a "little bit longer" but likely > several times as long. Also doing a bit refactoring always has > the risk of regressions and without unit tests *and* integration > tests these are hard to discover so often I just do not dare. > > Regards, > Arvin > 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. Josef -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
