With a large codebase for over 7 years, the unit tests carries a legacy. It has been designed and built with technologies then and with special purposes: to run both Unit Tests and Integration Tests with the shared test code. In short, the actual tests are used for both scenarios. We dropped the Integration Tests a few years ago. The remaining unit test works fine.

However, the original design carried a complexity cost. It was hard to understand for both human and machine, cumbersome to add new tests.

I tried to simplify it. Failed. I knew how to do. The effort was simply too high. It would have taken months.

Claude Code came. It was time to give it another try.

So I asked:

<A few words of context and my intent>. Propose options and discuss with me. Ask questions to clarify.

After a few rounds, I decide an approach. Then tell it to generate and save the plan or spec in a markdown file.

Store artifacts between phases.

A master plan was generated with phases. After around 10 days working with Claude Code, mission accomplished.

The remaining are 5.166 useful tests.

I did not have any Skill or Instruction files for this test. It was purely the effort between me and Claude Code. Claude Code is brilliant in solving issues especially there is a way to verify outcome. In this case, the tests must pass and it has original tests and production code to compare and explore.

The master plan it generated was not complete. There were many missing features. After done the master plan, I pointed out a few places and asked it to explore again. It was an iterative process.

===================SOME NOTES WHILE WORKING============================

The approach Claude Code takes: 

Create two artifacts "UNITTEST_PLAN.md" and "PROGRESS.md". The first is the master plan. The second is progress tracking. For each feature, tell CC

read @UNITTEST-PLAN.md and @PROGRESS.md suggest the next feature to migrate

Running the old tests takes time and consumes tokens. I told Claude Code this

I watched Claude Code did. There were germs along the way that I picked and learned.
In the existing test code, the "UnspecifiedActorRequest" object is constructed in many places and they look ugly. Claude Code come up with this:

A wrapper class that allows the test code to vary the data and unify the constructor in one place. Think about the situation when the "UnspecifiedActorRequest" constructor changes, adding more parameters. With the wrapper, just change one place in the test code. Brilliant!

For each migrated feature, there are a handful of failing tests. It took CC hours to fix them. Sometimes, it was impossible. I corrected them for CC. Some tests are no longer valid.

And later in the progress, it forgot the MutableActorRequest. It sounds like human. We forgot things we designed. The scope is too big.

Claude Code did most of the work. I helped it here and there with my knowledge and I knew where to fix things. Also that saved tokens.

In the process of porting features, soon, there were many duplicate methods between features. Told Claude Code to explore and move them up to base class.

I used "/clear" to start a new feature. However, it seems to be a problem after a while. Use "/exit" and start over. Surprisingly, It behaved differently than "/clear" a session.

Once a feature was migrated, old files were deleted. Most of the times, Claude Code checked to ensure there were no cross references before deleting. And, a few times, it did not. We could not assume. I asked it to update the plan.