在尝试进行测试驱动开发时，处理方法中发生的转换的最佳做法是什么？
是创建静态实用程序方法来执行转换，然后在这些实用程序方法上编写单元测试吗？我觉得问题在于，当您针对调用此实用程序方法的父方法编写测试时，您必须考虑发生的转换，因为大多数模拟框架不模拟实用程序方法。因此，编写处理父方法的验证方法变得困难。
我想到的另一个选项是创建一个负责转换的接口，并在测试调用方法时模拟该接口。接口旁边会有一个实现。这样做的问题是，似乎编写了额外的代码只是为了进行转换，并且在配置 IOC 容器时需要考虑许多新的依赖关系。
一个完美的例子是一个控制器动作，它需要从视图模型转换为实体，该实体是它连接到的服务的输入。这方面的最佳做法是什么？
【问题讨论】：
您可以Moq了解更多信息，如何使用带 TDD 的最小起订量请查看以下链接
有关 TDD 的更多信息，请查看以下链接
TDD/BDD screencast/video resources
Improve the Design and Flexibility of Your Project with Extreme Programming Techniques
Best Practices of Test Driven Development Using C# and RhinoMocks
【讨论】：
我会使用Automapper。它专为处理这种情况而设计，其大部分核心已经过单元测试。您可以编写一些非常基本的单元测试以确保您的转换始终有效，但这可能不优先于您尝试进行单元测试的其他事情:)
【讨论】：
Mapper.Map(source,dest)没有任何接口。但是，我不确定您为什么要模拟/包装这些方法调用...您可能希望将这些直接作为控制器测试的一部分进行单元测试，等等...有关您为何特别关注的更多背景信息试图模拟/包装这些？