Your top level algorithm nicely shows that the first test is very different than subsequent tests. I like you explanation of makeTestMoreMeaningful() and application of SRP.

Nice job refactoring my refactoring steps!

James

It was great time for us to work with you and to build feasible solution for our own environments. We couldn’t do it without you.

In this article, you quite clearly summarized lots of lesson learned we’ve figured out. Thanks.

The followings are my idea.

1) Adding top-most algorithm

In my oppinion, why don’t you put the top-most algorithm on the beginning of this article something like below:

attackLegacyCTests() // active and aggressive attitude
{
addNewLegacyCtest();
addMoreLegacyCtests();
}

2) Describing makeTestMoreMeaningful()

You skip to describe makeTestMoreMeaningFul(). But, in this step, I think that there are good noticeable points what we usually passed over.

—
makeTestMoreMeaningful()

Don’t use arbitary, unmeaningful, name such as Test1(), FirstTest(). The name of tests should be taken to show what’s exactly supposed to do. If it is hard to give a simple and concrete name on the test, it might have more than one responsibilities. If so, it’s time to break it by SingleResponsibilityPrinciple.
—

3) Refactoring long addMoreLegacyCTests() algorithm

I think that extracting refactoring steps as another function helps more clear.

addMoreLegacyCtests()
{
while (!testsAreSufficientForCurrntNeeds())
{
copyPasteTweakTheLastTest();
refactorTests();
}
}

refactorTests() // or keepTestsClean()
{
while (!testDifferenncesAreEvident())
{
inspectTheCopyPastedTests();
if (setupStepsAreSimilar())
{
extractAndParameterizeTheCommonSetup();
extractAndParameterizeTheCommonAssertions();
}
else
;//Maybe a new test case group is needed
}
}

Thanks again, James.

Knowing that it will crash and accepting it as a progress relieved us a lot. Without it we might have exit(FAILURE) Thank you for clarifying this process and your guidance which kept us in the right way.