开云体育

I think you might be over-thinking this. I would probably just refactor the class using the existing tests. I don't see the need to modify the tests themselves until you discover a value in changing the interface.

That is, the most common case I can think of would be to extract one of more delegators, leaving the rest of the system to invoke the original class, which is now at least partially a facade for the delegators. If for some reason you want to completely separate the classes so that the rest of the system will start calling the delegators directly, now you have a new interface and new scenario which needs to be tested - so write that new test and THEN make the delegate directly visible.

On Sep 10, 2012, at 5:34 AM, arnonaxelrod wrote:

Hi all,

I feel pretty skilled in TDD, and I'm even consired the "TDD expert" in
my company, but nevertheless, there are some cases that I feel I don't
know how to handle properly, so I would like to hear other's opinions.

My problems is as follows:
Even though in general TDD helps me think of the core responsibility of
a class, and extract every other responsibility to dependent classes,
there are cases that after some time I realize that one of the classes
has multiple responsibilities and it needs to be refactored and split it
into 2 classes. This conclusion often comes because the tests of that
class start to become complicated or repetitive. I can pretty easily do
refactoring to split this class to the design I want (and I do it in
small steps, keeping on the green bar). My problem is that I end up with
the same complicated and repetitive tests that now tests the 2 classes
together, while I would like to have seperate tests for each class.
The only (more-or-less safe) manner I could think of for doing that, is
to do the following for each test (after I completed the refactoring of
the production code):

1. Duplicate the test case
2. Change one copy of the test to use a mock instead of the 1st
class, and the other copy of the test to use a mock instead of the 2nd
class.
3. Then if I see that an identical test already exists for one of the
copies, I delete it.

I think that sometimes its possible to do the following:

1. start by creating the 2 classes from scratch (using TDD of course)
2. Change the old tests to use the new classes instead of the old one
3. Delete the old class
4. Delete the old tests

Both of these techniques seems pretty cumbersome and time consuming, so
I wonder: how do the "real experts" go about this issue?







------------------------------------

Yahoo! Groups Links

-----------------
Come read my webnovel, Take a Lemon <>,
and listen to the Misfile radio play <>!

It's a refactoring question, but what the heck?

Alternative path:

Start by creating A2, which inherits everything from A (classes
essentially identical other than access permissions).

Make A's private methods/properties protected.

One at a time:
Create A2 tests, by slowly (one-at-a-time) adding tests or moving
tests from A's test suite.
Where an A test might need A2 support, mock it.
As properties not needed by A to A2.
Move methods not tested in A to A2.

Drop the inheritance relationship between A and A2.

Don't test A2 through A. Test A2 directly, test A with mocked-out A2.


This is off-the-cuff at 9pm after a long day, so feel free to
embellish as needed.

--
Tim Ottinger, Sr. Consultant, Industrial Logic
-------------------------------------