在TDD中，在重构期间将主类拆分为子类 [英] In TDD, splitting main class into sub classes during refactoring

问题描述

我正在尝试关注TDD并且对它有点新意。我有一个要实现的接口（Java）。

所以我开始为接口行为编写测试用例，使它们失败并通过添加或修改代码来修复它们。 / p>

但是，正如我看到主类的大小正在增长，我将主类分解为单独的类。但是对于一些子类，我意识到最好单独测试它们并在主类测试用例中模拟它们。

但是当我这样做时，我不得不再次重写主类测试用例（对于移动的代码）导致大量的流失和重复工作。

我在实施TDD方法时做错了什么？

解决方案

听起来你正确的做得对。但是，有几点要做。重申以确保我们在同一页面上：

从主要类A中提取助手类B，

• 重构B出A


• 为B编写测试（借鉴A的测试）


• 如果合适的话，删除由B


• 的测试复制的A的测试，重写剩余的一个或多个A的测试，这些测试依赖于B中现在的功能来使用B的模拟

一些建议：

• 在解压缩辅助类之后，您可以删除测试帮助程序类功能的主类中除一个（或几个）测试之外的所有测试。所以你不应该对剩下的主类进行很多测试需要重写。

  
  
  

  例如，如果主类为一个人建模并且辅助类构造了这个人的从他们给定的姓名，姓氏，职称等全名，主要课程最初会对该功能进行多次测试：一个给定名称与一个以上，标题与无标题等。你会写对于辅助类的等效测试，然后删除除了一个与全名构造有关的主类测试之外的所有测试。你需要在主类中留下一个测试，它测试它知道如何构造某种全名;如果你错误地删除了对助手类的调用或者那样的话，那么测试就会失败。




• 如果助手类很简单（特别是如果它没有需要特殊测试设置的重度依赖项或导致它很慢），你不必模拟它。这可能会省去你对主类测试的重写。




• 此过程确实需要重新测试测试和代码。 通过提前思考并尽快进行重构来最大限度地减少返工，一旦你说服自己会有所帮助。我发现当我认为我需要提取课程时我通常是对的;我很少在以后上课。因此，积极提取类通常不会导致额外的工作，而是通过更快地获得正确的对象模型来最小化它。

I am trying to follow TDD and am kind of new to it. I have a interface (Java) to be implemented.

So I started writing test cases for the interface behaviour, making them fail and fixing them by adding or modifying code.

However, as I see the main class is growing in size, I am breaking the main class into separate classes. But for some of the sub-classes, I realize that it's better to test them separately and mock them in the main class test cases.

But when I did that, I had to rewrite the main class test cases again (for the moved code) resulting in lots of churn and duplicate work.

Am I doing anything wrong in implementing the TDD methodology?

解决方案

It sounds like you're doing it about right. There are a couple of points to make, however. Restating to be sure we're on the same page:

To extract a helper class B from the main class A,

• refactor B out of A
• write tests for B (drawing on the tests for A)
• remove tests of A that are duplicated by tests of B
• if appropriate, rewrite the remaining test or tests of A that depend on functionality now in B to use a mock of B

Some advice:

• After you've extracted the helper class, you can remove all but one (or maybe a few) of the tests of the main class that test helper class functionality. So you should not have many tests of the main class remaining that need to be rewritten.

  For example, if the main class models a person and the helper class constructs the person's full name from their given name(s), surname, title, etc., the main class would originally have many tests of that functionality: one given name vs. more than one, title vs. no title, etc. You'd write equivalent tests for the helper class, then delete all but one of the main class tests that are about full name construction. You do need to leave one test in the main class that tests that it knows how to construct a full name of some kind; that test will fail if you mistakenly remove the call to the helper class or something like that.

• If the helper class is simple (in particular, if it has no heavy dependencies that require special test setup or cause it to be slow), you don't have to mock it. That might save you some rewriting of main-class tests.

• This process does require rework of tests as well as code. Minimize the rework by thinking ahead and doing the refactoring as soon as you convince yourself that it will be helpful. I find that when I think I need to extract a class I'm usually right; I rarely have to inline the class later. So being aggressive about extracting classes does not usually lead to extra work, but instead minimizes it by getting to the right object model sooner.

这篇关于在TDD中，在重构期间将主类拆分为子类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！