上个星期我们只是显示了一个示例，怎么在EF的框架内，注入我们拓展的动态过滤器

第一步：安装EntityFramework.DynamicFilters

第二步：重写OnModelCreating方法

        添加：modelBuilder.Filter("BlogEntryFilter", (BlogEntry b, Guid accountID, bool isDeleted) => (b.AccountID == accountID) && (b.IsDeleted == isDeleted),

                                                () => CurrentAccountID, () => false);

回顾上个星期的示例，我们只是知道怎么把EntityFramework.DynamicFilters与EF结合起来。

示例里面能展示的场景太少，那么在我们实际的使用过程用，可能会遇到各种场景，这个时候我们怎么才可以快速的知道，自己想加的过滤条件该怎么加呢？

答案是参考单元测试，下面是单元测试的示例图：

我不会没有关系，去网上找，网上解释的什么叫单元测试

   单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

为什么要进行单元测试

单元测试有什么好处呢？

1、它是一种验证行为。

程序中的每一项功能都是测试来验证它的正确性。它为以后的开发提供支援。就算是开发后期，我们也可以轻松的增加功能或更改程序结构，而不用担心这个过程中会破坏重要的东西。而且它为代码的重构提供了保障。这样，我们就可以更自由的对程序进行改进。

2、它是一种设计行为。

编写单元测试将使我们从调用者观察、思考。特别是先写测试（test-first），迫使我们把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合。

3、它是一种编写文档的行为。

单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。

4、它具有回归性。

自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地的快速运行测试。

编写单元测试，有什么想的原则可以让我们参考呢？

要遵守3R（Responsible, Reliable, Repeative）原则

• Responsible: 谁开发谁负责测试，在哪里开发就在哪里测试。
• Reliable: 测试case要可靠，并且是值得信赖的，对于底层的任何改动都要能够及时感知。
• Repeative: 所有单元测试用例都要能够重复运行。能够重复运行就能够进行回归测试、覆盖率统计等等。

• • 如何做到Responsible？
    开发在完成一个方法，或者一个类之后，就要及时得进行单元测试；不能在对应方法或类的调用处进行测试，比如两个模块A、B，A是基础模块，为模块B提供服务，那么所有A模块的单元测试case都应该在A模块的内部进行测试。
  • 如何做到Reliable?
    为了使得测试用例尽量可靠，就要减少mock的使用（对于第三方的调用可以使用mock），对每层代码的测试都要完全依赖于下层，不能mock下层逻辑。因此引入递进集成的概念，比如测试DAO时要连接真实的数据库，测试Service时要使用真实的DAO、DB， 测试Controller层的代码，要使用真实的Service、DAO、DB，以此类推。这样就可以最大限度的提高case的可靠性。
  • 如何做到Repeative?
    必须要做到case间完全解耦，没有任何的依赖，这包括和数据库的依赖以及第三方的依赖。case解耦可以通过准备测试数据、mock第三方调用来解决。