CODEWITHSUNDEEP
unit-testingjunittdd
Vytenis Bivainis
Vytenis Bivainis

Reputation: 2366

Should new test classes be created after extracting classes in production code?

Assume I have a big so called legacy class A. Then I write ATest so that I can safely refactor A. Then I extract many classes, for example, A calls B, B calls C, C calls D. ATest still covers A, B, C and D. Now ATest is almost an integration test since it covers more than one or two classes (although same functionality as initially). Now could you advice me (or give some references) whether I should invest a lot of time in splitting ATest into BTest, CTest, DTest. If so, should I do it immediately? If I have to add new functionality to D, should I create DTest without touching ATest (option 1), add test methods to ATest(option 2) or move tests from ATest to DTest and add new test methods there (3)?

Upvotes: 2

Views: 67

Answers (1)

Gembles
Gembles

Reputation: 21

Firstly, ensure that ATest is a pure integration test - i.e. it isn't just a load of unit tests across multiple classes.. by which I mean ATest does not care HOW anything is done, just that the end result is correct. i.e. It does not care HOW you build the car, just that a car is built. This is important.

Ideally, you should then specify the BTest, CTest, DTest prior to writing each of the classes so that:

a) you clearly define the role of each class

b) you are sure that each part is correct prior to moving on to the next

c) you allow for easy future problem isolation (i.e. isolating the failing component - B,C or D from their respective failing test)

In the end you should have a passing unit test for each class and an integration test for the process.

Adding a feature: write the unit test, then the class. Then if it impacts the core outcome of the process (like instead of the end product being a car, it's a bike!), add an integration test, otherwise, no integration test should be required.

Upvotes: 2

Related Questions