• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Refactorings and testing

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is actually common practice to have *both* kinds of tests in place.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic