MSTEST是否生成实际的单元测试?

如果您已经做了必要的工作来隔离依赖项,那么自动生成的测试只是单元测试,这样具有副作用的调用就可以路由到适当的模拟或存根依赖项来感知所需的效果。这些工具不能完成构建代码以支持单元测试的工作;它们所能做的只是创建对各种公共访问点的调用。您还需要为每个测试安排依赖状态,并断言您希望检查的条件。

MSTEST,afaik,将不够聪明,不知道如何模仿它测试的行为。因此,如果您不嘲笑用户自己的DB依赖性,那么它就不是单元测试。

像mstest和nunit这样的“单元测试”框架只提供运行一套编程测试的环境。您用[test]属性或类似属性修饰一个方法,它将运行它。根据测试所涵盖的代码范围,该测试可以是单元级、集成级、功能级,甚至是验收级。在我们的项目中,除了集成测试,我们什么都没有,它涵盖了功能的整个垂直部分,甚至模型客户机验收测试用例。所有这些都是使用nunit框架编写的。

您的开发环境不能阻止您在开发中犯错误;如果是这样,就不需要进行QA。

所有这些单元测试框架实际上并不局限于进行单元测试。

您可以使用这些测试来执行许多不同的测试类型,包括完整的系统测试和集中的集成测试。特别是当您添加从测试代码/运行程序使用的额外框架工具时。

如果您有一个非常瘦的类,它的唯一职责是与外部系统集成,那么如果您围绕它创建测试,那么这些测试是集中的集成测试,最好是命中外部系统。只需确保将它们与单元测试分开,因为它们自然会变慢。

另一方面,如果对外部系统具有硬依赖性的类不仅仅是一个瘦类,那么问题在于代码;)。解决它,本质上你的测试不会有这个问题。