You are feeling the pain that happens when tests are not written to be independent. Step one is making all of these tests independent. Break the dependency between testInitialDataCleared and all the other tests. Odds are all tests call the first one in order to simplify the setup for each test.

Consider moving the minimal common test setup logic into a reusable utility method. I would advise against calling this common setup method inside testInitialDataCleared just to keep the first test independent. Besides, you want to remove that test anyways.

It is fine for tests to have a common setup routine. It’s not good when the first test is the setup routine. Once the tests are independent, remove the code in your system under test, followed by removing the obsolete tests and changing the common setup for the remaining tests. The rest of the job should go easier and reveal itself after that.

As you add, remove, and change tests, keep in mind that a unit test is defined by the requirement being tested, the smallest unit of code necessary to implement the requirement, and the minimum number of assertions needed to ensure the test fails if the unit of code no longer implements the requirement.

I think it is hard to give you reasonable advice without knowing the whole system, but my best guess is that you changed the Manager class to not call clearInitialData() anymore, and your test suite helped you to achieve this goal correctly.

So far, so good. However. sending clearInitialData() surely had a purpose for the business logic – just removing it will probably cause unwanted side effects which will only become apparent when the business logic gets run.

So what you need to understand first and foremost is to understand what removing clearInitialData() will mean for the BL part of your code. Ideally, the business logic part (in isolation) will work correctly with or without clearInitialData() called before, the decision whether it is called or not is done at a different level in your code and should be kept orthogonal to the BL itself (including all tests of the BL). The fact the assertions now fail show the BL currently isn’t designed that way.

If you want to approach this by TDD, what you need to write here first is

• one or more unit tests which run the affected business logic without the Manager class

• a parameter to let the test setup control whether clearInitialData() is called before or not (it does not have to be clearInitialData() itself, but some equivalent method which simulates the effect from the point of view of the business logic code)

Then you can use this test in TDD style to prepare the business logic for the upcoming change. When you are done with this, then it is time to start changing the Manager class and it’s testsuite, which should ideally result in a more successful outcome.

Most of your failing tests are making an irrelevant assertion. Fix that before performing the change.

The test should assert whatever is relevant for the use case it emulates. As you have test failures removing irrelevant code, the tests were doing unnecessary assertions. Fix the tests to stay focused on their own scenario and result, without asserting unnecessary environmental details.

Unrelated Unit test tangent

There is an opinion in the industry that each unit test should make exactly one assertion. The stated benefit is that a failure reason is clear at a glance and error is easier to localize. The reasoning is invalid, as the first assertion to fail is the only one that matters when investigating a test failure.

In your case, the problem is not multiple assertions, but assertions that are not related to the test scenario.

Anyway, this is unrelated, as we deal with an integration test and opinions on integration tests are less strict and mostly less stupid.