>我有一个大方法，我把它分成几个方法，并把它们放在同一个类中。
例：
public void Method(int param)
{
var result = this.DoSomething(param);
this.DoSomethingElse(result);
}
但是现在我无法测试此方法，因为我无法模拟其中的方法，因为它们在被测试的类中。
较小的方法在同一类中重用，但不在类外部重用。将它们放在不同的类中并将它们作为依赖项提供以便我可以模拟它们是一个好主意吗？
还是方法本身不值得测试，只测试较小的方法就足够了？
常见的方法是创建一个不同的类，在其中定义这些较小的方法。然后在主类中创建此不同类的实例来调用其方法。例如，这个不同的类被称为ClassSmallMethods(你应该选择更合适的东西(。然后在主类中创建另一个类的实例：
ClassSmallMethods ClassInstance = new ClassSmallMethods();
假设您的类ClassSmallMethods中有一个名为public string ReturnString()的方法返回一个string。现在你可以调用这个方法，对于exmaple，获取该方法返回的值。(或者用该方法做任何你想做的事情(：
string randomString;
randomString = ClassInstance.ReturnString();
我有一个大方法，我把它分成几个方法并把 他们在同一个班级。
它被称为重构(提取方法( - 您正在更改实现而不更改行为。这就是您不应该测试实现细节的主要原因。当类的行为未更改时，测试不应失败。这将允许您轻松地在类中进行大量小重构 - 更改算法，拆分方法，更改内部使用的数据类型。您的测试而不是失败将帮助您看到行为仍然正确实现。
例如，如果您正在测试比萨店，那么您不在乎他们的厨房有多大，谁在厨房工作，以及他们使用的烤箱型号。您只对比萨店的行为感兴趣 -CookPepperoni()应该返回所需质量的正确比萨饼。
将它们放在不同的类中是个好主意吗
好吧，从技术上讲，这也被称为重构 - 提取类。但这是Martin Fowler对重构的定义：
重构是一种用于重组现有 代码主体，在不更改其内部结构的情况下更改其内部结构 外部行为。
所以，这是一个带有一点注释的重构 - 系统的行为不会改变，但被测试类的行为会改变 - 它现在应该与外部依赖项交互。就像比萨店一样 - 如果您要向盒子工厂引入依赖关系，那么比萨店的责任将涉及从工厂拿走盒子。这应该用模拟来测试。
这种重构会破坏你的测试。反之亦然 - 如果您正在练习 TDD，那么您应该更改测试以检查新的预期行为。然后在测试失败后，您应该提取类并再次使测试变为绿色。