我是单元测试的新手，似乎我找到的大部分信息都在单元测试方面。我正在很好地掌握这一点，并计划将 MS 测试框架与 Moq 一起使用，这样我就不必为我的单元测试依赖项手动滚动任何模拟。
假设我有以下单元测试方法：
[TestMethod]
public void GetCustomerByIDUnitTest()
{
//Uses Moq for dependency for getting customer to make sure
//ID I set up is same one returned to test in Assertion
}
我是否必须创建另一个相同的测试，而不是使用实际的实体框架和数据库调用来进行集成测试？
[TestMethod]
public void GetCustomerByIDIntegrationTest()
{
//Uses actual repository interface for EF and DB to do integration testing
}
出于此问题的目的，请省略有关TDD或BDD的主题;我只是简单地试图确定我是否需要 （2） 单独的测试以及组织这些测试的方式。在进行单元测试和集成测试时，这是必需的吗？
谢谢！
在我看来，这有点情境化。如果我正在做一个小型的个人项目，那么不，我只是做单元测试。
如果是公司/企业项目，那么我确实倾向于同时进行单元和集成测试。但是，请保持单元测试和集成测试分开。开发人员应该能够频繁快速地运行单元测试。集成测试的运行频率可以降低，因为它们通常需要很长时间才能运行。通常我只在提交之前运行一次集成测试，而我运行单元测试的频率要高得多。
作为附加说明，请让您的测试名称解释应该发生的情况。测试名称GetCustomerByIDUnitTest真的没有告诉我太多。最好是这样的：GetCustomerByID_ReturnsTheCorrectUser_WhenAValidIdIsPassed，反之GetCustomerByID_ReturnsNull_WhenNonExistantIdIsPassed
我倾向于What_Does_When命名约定，但这也是个人喜好。一般来说，解释性越好。
嗯，我希望我不会因为提到你宁愿没有提到的事情而让你失望。但在这里我花了 2 美分。预先发布一份免责声明。我将nunit与RhinoMocks一起使用，因此语法可能不同，但概念是相同的。
是的，您需要单独的测试。您可以争论是否要将测试存储在同一个测试类中，并用[Category("integrationtest")]标记它们，以便可以轻松地运行单元测试而无需运行集成测试，反之亦然。通过你的TDD实践（哎呀，我知道你不希望我谈论那个:)），你需要尽快完成你的单元测试。
从稍微不同的角度来看这个问题;你并没有真正重复你的测试。集成测试验证功能，而单元测试单独验证方法。所以他们很可能有完全不同的名字。只要它们对你有意义（或者如果你与团队一起开发一些东西：只要它对你的团队有意义）。
我认为最重要的是你找到一种适合你的方法。真的没有对错之分。我认为您同时编写单元测试和集成测试是一个很大的优势。你如何组织它们有点取决于你。在我参与的不同项目中，我有不同的方法：
项目A：
- 1 个用于集成测试的测试类
- 1 个用于单元测试的测试类
这有助于为测试类创建有意义的名称，它们可以捕获我们正在测试的实际功能。至于单元测试，测试类与我们正在测试的类具有相同的名称。
项目B：
- 将集成测试与一个测试类中的单元测试混合在一起。
这也很好用，尽管我们有时确实很难找到集成测试。但是，有锐利器在你身边，:)能有多难。
据我所知，您应该有单独的单元测试和集成测试项目。本书的建议是创建两个项目，并将它们命名为ProjectName.UnitTests和ProjectName.IntegrationTests。开发人员必须单独轻松地运行它们中的每一个。
您可以在此处找到许多有关测试的有趣主题和视频