Class extraction with TDD'ing. How to check a new extracted class?

Question

So, I had several methods in my main class that used a matrix to set pixels on or off. I have all the current tests running, and I decided it was time to pull out the part of this logic related to the matrix and create the Matrix class.

My question is, besides the tests that I have for my SUT class (I’m only at the beginning, so currently I only have one class, the main SUT), should I create Unit-Tests tests? If so, how do you do it? I mean, will I allow all my codes, as of now, to create module tests one by one, making the first approach to testing, until I see that I have everything functionally, what I want in it, and only there I will reorganize your code? I just create a Matrix class and just verify that the old tests still pass, and that everything is fine?

thanks

Answer 1

Basically the last one. There is no need to check a class just because it is defined as a separate class. If you refactor without adding any functions or otherwise change the behavior, the only reason you add tests is your lack of confidence in a specific part of the code. Otherwise, the code is already being tested, and the fact that it was tested through another class does not matter.

As they say, there are times when the structure of the code has changed so much that for organizational purposes you want to transfer the test, so you can tell exactly where this part of the code is checked. But this is another question: to say that "it is an independent unit, so it should have independent tests."

Answer 2

One of the relatively common hints that class germination time is that you have private methods that you want to test. In this situation, let the tests really control refactoring. Write a test for the (currently private) method in a (as yet unwritten) class; give an instance of a new class to an existing class and move the private method to the new class, making it public when you go.

Answer 3

For this kind of refactoring, the compiler should guide you. Take everything you want into a separate class and compile. He will tell you where you need to use the new class in both production code and tests. Refactor everything until it compiles and repeats.

The right way to do this is to move the methods / properties one by one, it only depends on how comfortable you are with the process.

EDIT You only need to create enough tests to cover the code. For the organization, you must transfer the tests, which were in the main test class, to a separate class, but more about that. If you need to write more code for the refactoring process (for example, a method that creates an instance of a new class), you should also write tests for this.

Say you start with a class and a test class:

OneBigClass -Method1 -Method2 -Method3 OneBigClassTest -Method1ShouldDoSomething -Method2ShouldDoSomething -Method3ShouldDoSomething 

After refactoring, it will look like this:

 OneBigClass -Method1 -Method2 SmallerClass -Method3 OneBigClassTest -Method1ShouldDoSomething -Method2ShouldDoSomething SmallerClassTest -Method3ShouldDoSomething