对于你们中的一些人，我的问题可能显得很愚蠢，但我不得不问......抱歉..
我真的不了解单元测试的原理。如何在不修改数据库的情况下测试业务类或数据访问层的类？ 我解释说，我有一个更新数据库中的字段的功能..没有什么比这更令人惊奇.. 实例化业务层类，方法BLL.Update（）进行一些控制，最后实例化一个DAL类，该类使用正确的参数在数据库中启动存储过程。
它的作品，但我的问题是......
要进行测试DALayer类的单元测试，我必须在测试中影响数据库！例如，为了测试值5是否传递给DataBase，我必须这样做，测试后数据库的字段为5！
所以我通常知道系统不会受到测试的影响所以我不明白你如何在没有执行方法的情况下进行测试。
Tx的答案，请原谅我可怜的英语..
答案 0 :(得分：7)
我会将你的问题分成几个子问题，因为很难一起回答它们。
单元测试x集成测试
当您编写单元测试时，您正在测试简单单元。这意味着您正在测试方法中测试单个执行路径。您需要避免像提到的数据库那样测试其依赖项。您通常会为每个执行路径编写简单的单元测试，以便您通过测试获得良好的代码覆盖率。
编写集成测试时，您正在测试所有图层以查看集成和配置是否有效。您通常不会为每个执行路径编写集成测试，因为所有层都有许多组合。
测试业务类 - 单元测试
您需要测试业务类，而不依赖于DAL和DB。要做到这一点，你必须设计你的BL类，以便从外部注入这些依赖项。首先，您需要为DAL定义抽象类或接口，并将该DAL接口作为参数传递给构造函数（另一种方法是在BL类上公开setable属性）。测试BL类时，您将使用另一个不依赖于DB的DAL接口实现。众所周知的测试模式Mock，Stub和Fake定义了如何创建和使用这些虚拟实现。许多测试框架也支持模拟。
测试数据访问层 - 集成测试
您需要针对真实数据库测试您的DAL。您将使用测试数据集准备测试数据库，您将编写测试以使用该数据。每个测试都将在自己的事务中运行，该事务将在最后回滚，因此不会修改初始数据集。
最好的问候，拉迪斯拉夫
答案 1 :(得分：2)
对于您在数据库交互方面描述的场景，模拟很有用。如果有机会，请查看Rhino Mocks
答案 2 :(得分：1)
您将Inversion of Control与模拟框架一起使用，例如犀牛模仿已经提到的人
答案 3 :(得分：1)
如果你没有在测试中使用模拟和使用实际数据库，那么它将以外行术语进行集成测试，而不再是单元测试。我参与了一个项目，其中一个专用的sql .mdf在源控件中，使用[SetupFixture]的[Setup]部分中的NUnit附加到数据库服务器，类似于[TearDown]中的分离。这是在每次执行NUnit测试时完成的，并且可能非常耗时，具体取决于您拥有的SQL代码以及数据大小可能会变得更糟。
现在捕获的是维护开销，您可以在sprint周期中更改DB scehma，并且在重新启动时，必须在开发和测试中使用的所有数据库上运行更改DB脚本，包括用于集成测试的数据库。上文提到的。不仅如此，新的测试数据（如上所述）必须为创建的新表/列提供popoulated，同样，由于需求更改或错误修复，可能还需要清除现有数据。
这似乎本身就是一项任务，团队中的某个人可以获得所有权，或者如果时间允许，您可以将变更脚本的执行作为持续集成的一部分进行集成，如果您已经实现了。仍然需要手动处理添加和清理测试数据。