Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Refactorings and testing

 
William Bernadsson
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am reading "Refactorings" book. It does strongly suggest to have unit test before doing any serious refactoring. But the refactoring may rearrange code, move functionality between methods and classes. As I understand unit test are unit based : class/methods. Then, the unit tests have to be refactored as well? How to keep unit tests match the tested code and do not introduce errors while refactoring?
 
Eric Nielsen
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Several things:

1) If your unit tests are testing the public interface of the class, and are focused on testing behavior rather than methods, the unit tests are somewhat resilient to many common refactorings (as they only change the internals of a class.

2) If your IDE offers built-in refactoring support, then when you use the built in refactorings, it'll take care of changing the test code when it has to.

3) If you've kept your test code refactored, even when you have to manually update test code to account for a new refactoring, you should only need to do it one place.
 
William Bernadsson
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1) If your unit tests are testing the public interface of the class, and are focused on testing behavior rather than methods, the unit tests are somewhat resilient to many common refactorings (as they only change the internals of a class.


I have to refactor the code that lays out products, marketing images, and other widgets on shop page. It is quite complex - about of 1000 java lines of code and logic is fuzzy.
This is huge amount for testing, right? I can approach it 2 ways:
1. Test input against output. I can create big input data chunk, put it into XML and test it against the output. This way I will never have to change test code. On the other hand such testing would not really point to the place/method that is faulty. It just will say - does not work. That would be more black box testing.
2. If I write tests per method/classes I will have to refactor them as well. This is where I am afraid to introduce errors. But such tests would easier detect the place of the error and they can serve as some sort of example how the specific methods can be used.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is actually common practice to have *both* kinds of tests in place.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic