相关疑难解决方法(0)

• 假设我们已经意识到TDD的价值太晚了.项目已经成熟,很多客户开始使用它.
• 假设使用的自动化测试主要是功能/系统测试,并且有大量的自动GUI测试.
• 假设我们有新的功能请求和新的错误报告(!).所以很好的发展仍在继续.
• 请注意,已经存在大量业务对象,没有或几乎没有单元测试.
• 它们之间的协作/关系过多,只能通过更高级别的功能/系统测试进行测试.没有集成测试本身.
• 大型数据库到位,有大量的表,视图等.为了实例化单个业务对象,已经进行了大量的数据库往返.

我们怎样才能在这个阶段引入TDD？

嘲弄似乎是要走的路.但是我们在这里需要做的嘲弄似乎太多了.听起来需要为现有的东西(BO,数据库等)工作的模拟系统开发精心设计的基础设施.

这是否意味着TDD只有从头开始才是合适的方法？我很想知道在已经成熟的产品中引入TDD的可行策略.

您是否有任何将单元测试改装到目前没有单元测试的代码库的策略？

我一直在编写一些从providerbase类继承的c#中的提供程序.我发现很难编写使用提供程序的测试,因为大多数模拟框架只允许你模拟一个接口.

有没有办法模拟对从providerbase继承的提供程序的调用？

如果没有,是否有一种模式可以用来实现提供者的模拟？

我听说通过单元测试我们可以捕获代码中的大部分错误,我真的相信这是真的.但我的问题是在大型项目中,每个类依赖于许多其他类,你如何进行单元测试？由于编写存根所需的复杂性和时间,所以对其他所有类进行存根没有多大意义.你对此有何看法？