• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Refactoring techniques and testing

 
Ranch Hand
Posts: 57
1
Redhat Notepad Fedora Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Chris,

Do you plan in your book to go into a detail of different refactoring approaches and their pros/cons? I see those chapters are not yet ready, but i would like to see some examples of e.g. red X green refactor method, refactoring by abstraction, composing technique, simplifying methods, moving features between objects and preparatory refactoring etc.?

I am particularly interested in relation to tests. Refactoring MAY cause old tests to fail, so in addition there might be some effort to create new tests. What amount of time should be invested as part of a refactoring effort of both in-depth and regression testing? To ensure that the functionality of the solution was not affected in any way... I hope you get my point.
 
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Lucian Maly wrote:I am particularly interested in relation to tests. Refactoring MAY cause old tests to fail, so in addition there might be some effort to create new tests.


If refactoring causes a test to fail, that's usually a signal that you messed something up while refactoring. What would your intent be in creating new tests when old tests fail as a result of refactoring?
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And just to level set on what we're talking about when we say "refactoring," I'm going by Martin Fowler's definition:

Martin Fowler wrote:Refactoring is the process of changing a software system in a way that does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence, when you refactor, you are improving the design of the code after it has been written.


This is from his book, "Refactoring: Improving the Design of Existing Code"
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For me, if an existing test fails after I did some refactoring, my first reaction would be "Shoot, what did I just mess up?" and then go back and make sure I understand what bug I just introduced.

If I'm fairly certain that my "refactoring" changes were correct then my next step would be to understand why they caused the existing test to fail / become obsolete. With that understanding, I'd write new tests to describe how the new code should behave.  Once the new tests pass, I'd delete the failing/obsolete tests. This isn't refactoring though because the behavior of the program is changed. If I wanted to feel really confident about these kind of changes, I'd back out the changes to when the old tests were still passing but keep the new tests. I would want the new tests to fail and the old tests to pass. Then re-apply the changes I want to make and see the old tests fail and the new tests pass.
 
Author
Posts: 31
8
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Lucian,

Thanks for your question, and sorry for the slow response time.

This book is intended to be very pragmatic as the primary target is people who have no prior exposure to refactoring, so I focus on giving them as much useful knowledge as I can without overwhelming them. Therefore I do not discuss different approaches to refactoring in-depth, although I might mention them in passing, so curious readers can go and research them on their own.

Regarding testing, I discuss it very little in my book for the same reason as above. Refactoring, by any definition, cannot change external behavior. So how can a test fail? I see a few ways refactoring can cause an existing test to fail. The first way, as Junilu said, is if something went wrong in the process of refactoring. This would be my first instinct and the first thing I investigated. Often it is just some human error or oversight, so if the refactoring was quick I would probably just reset my branch and do it again.

The second way is if the test is not in fact external. That is we can make refactorings that are breaking interfaces, as long as we have control over all the call sights. In this case, because the test is not external it should be treated as any other code while refactoring, and therefore it should be fixed in the same way other calls are.

The third way is if our tests are dependent upon internal structure, like a performance test. These are not explicitly connected to the code, so they are easy to overlook when refactoring. If you discover such a test after doing some refactoring you should investigate whether the test is still relevant and if it is then roll back the refactoring.

Hope that was useful
 
Switching from electric heat to a rocket mass heater reduces your carbon footprint as much as parking 7 cars. Tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic