Extracting class when TDD'ing. How to test the new extracted class?

Question

So I had a couple of methods in my main class that used a matrix to set pixels on or off. I got all my current tests running and so, and I've decided it's already time to pull out some of that logic related to the matrix and such and create a Matrix class.

My question is, besides the tests I currently have for my SUT class (I'm just in the beginning, so I currently only have one class, the SUT's main one), should I create Unit-Tests for it? If so, how do you do it? I mean, do I let all my code as it is right now, create make unit tests one by one doing test first approach until I see I have all the functionally I want in it and only there I refactor my code? I just straight create the Matrix class and just make sure the old tests are still passing and that everything's ok?

Thanks

Answer 1

Basically the latter. There is no need to test a class just because it is defined as a distinct class. If you are refactoring without adding any functionality or otherwise changing behavior, the only reason to add tests is if you lack confidence in a certain part of the code. Otherwise, the code is already under test, and the fact that it is tested via another class should not matter.

That being said, there are times where the structure of the code has changed so much that for organizational purposes you want to move the test, so you can tell where this piece of code is actually being tested from. But that is a different question from saying that "this is an independent unit, so it must have independent tests."

Answer 2

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

The proper proper way of doing that is moving methods/properties one by one, it just depends on how comfortable you are with the process.

EDIT You only need to create enough tests to cover you code. For the sake of organisation you should move the tests that were in the main test class into a separate class, but that's about it. If the process of refactoring requires you write more code(e.g. a method that creates an instance of the new class), you should write tests for that as well.

Say you start off with a class and a test class:

OneBigClass
 -Method1
 -Method2
 -Method3

OneBigClassTest
 -Method1ShouldDoSomething
 -Method2ShouldDoSomething
 -Method3ShouldDoSomething

After refactoring this is what your classes should look like:

OneBigClass
 -Method1
 -Method2

SmallerClass
 -Method3

OneBigClassTest
 -Method1ShouldDoSomething
 -Method2ShouldDoSomething

SmallerClassTest
 -Method3ShouldDoSomething

Answer 3

One relatively common hint that it's time to sprout a class is that you've got private methods you want to test. In that situation, let the tests really drive the refactoring. Write the test for the (currently private) method in the (as yet unwritten) class; give an instance of the new class to the existing class and move the private method into the new class, making it public as you go.