By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,285 Members | 1,659 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,285 IT Pros & Developers. It's quick & easy.

Refactoring test units after an extract method

P: n/a
This is not strictly python related, but it's not strictly TDD related
either. Anyway, here it goes.

There's something that I was never quite sure how to handle with test
units: How to handle the test unit refactoring after a method
extraction.

Let's say that you have a function foo() that does A and B. You have
tests for foo() that check that A and B are executed properly. Then,
you add another function, bar(), that needs to do B, so you add a
third function, baz() that does B and make foo() and bar() call baz().

How to you handle the tests? Copy over the tests you had for foo() and
apply them to bar()? I don't like copy and pasting code. Move the B
related tests to baz()'s tests? Then your tests wouldn't fail if you
stopped calling baz() in foo() and bar().

What I do right now is that I mock baz() and verify that it is called
in foo() and bar(), with the right arguments. Then I move the B
related tests to baz(). It kind of works, but somehow, it doesn't feel
like the ideal solution to me. But then again, it's kind of the same
thing as if baz() was a third party function: You have to mock it to
test foo() and bar() properly without testing the third party code.

What do you people think?

Jun 5 '07 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.