Common Concerns with Automated Tests & Refactoring

Below is a list of common concerns that the average non-refactoring/non-automated-testing person might have towards Refactoring and Test-Driven Development.

All of these concerns have already been addressed, but I'll be going from memory. I want to make sure I still understand how Refactoring and TDD are supposed to help -- since I've been confronted as if I've lost my mind.

CONCERNS:

  1. Developers won’t be able to support it anymore.
  2. Developers will have to reverse engineer refactoring efforts which will decrease their productivity.
  3. Version Control becomes muddied: Refactoring design changes cannot be discriminated against bug fixes.
  4. It is not fair to other coders. It implies that their work is unqualified or sub standard.
  5. Refactoring nullifies any unit testing that the developers did in creating the classes which decreases accountability in system design.
  6. You can be sure I will be after the author is something breaks or needs to be redone. No need to make that a blurry picture.
  7. It does not project a “Team Spirit”.

REMEDY:

  1. Refactoring by definition is, "A code refactoring is any change to a computer program which improves its readability or simplifies its structure without changing its results". By making the code easier to read, it will be easier to support.
  2. See Remedy #1
  3. See Remedy #1
  4. It's a team. One team member that writes bad code, it can bring the entire team down. If anything, the team members that have their code refactored will be learning and will begin to write tighter code that has less defects in it. The company's ROI for that programmer increases over time.
  5. Were there tests to begin with? If there WERE tests that BROKE because of someones refactoring, was it for the better or worse? The unit-tests should be changed to reflect any business changes to the refactoring.
  6. Don't check in broken code. Simple as that. If you have unit-tests breaking, are you going to check it in?
  7. It projects "Lets work together and write better/cleaner code so we don't have to work 80 hour work weeks". I guess if your team really does love working on the weekends and 12-16 hour days , then keep on truck'n how you are.