I'm faced with similar classes A1, A2, ..., A100. Believe it or not but yeah, there are roughly hundred classes that almost look the same. None of these classes are unit tested (of course ;-) ). Each of theses classes is about 50 lines of code which is not too much by itself. Still this is way too much duplicated code.

I consider the following options:

1. Writing tests for A1, ..., A100. Then refactor by creating an abstract base class AA.
   Pro: I'm (near to totally) safe by the tests that nothing goes wrong.
   Con: Much effort. Duplication of test code.
2. Writing tests for A1, A2. Abstracting the duplicated test code and using the abstraction to create the rest of the tests. Then create AA as in 1.
   Pro: Less effort than in 1 but maintaining a similar degree of safety.
   Con: I find generalized test code weird; it often seems ... incoherent (is this the right word?). Normally I prefer specialized test code for specialized classes. But that requires a good design which is my goal of this whole refactoring.
3. Writing AA first, testing it with mock classes. Then inheriting A1, ..., A100 successively.
   Pro: Fastest way to eliminate duplicates.
   Con: Most Ax classes look very much the same. But if not, there is the danger of changing the code by inheriting from AA.
4. Other options ...

At first I went for 3. because the Ax classes are really very similar to each other. But now I'm a bit unsure if this is the right way (from a unit testing enthusiast's perspective).