根据子句的初始化方式，不同的约束作用于返回值

• some_call 专为仅发生一次的调用定制。返回值没有 [Clone] 约束。
• each_call 专为预期发生多次的调用定制，因此需要在返回值上要求 [Clone]。
• next_call用于验证确切的调用序列，否则与some_call的工作方式相似。

修改输入

许多特性使用参数修改模式，其中有一个或多个&mut参数。

要访问&mut参数（并修改它们），需要使用answers对调用模式应用一个函数

let mocked = Unimock::new(
    mock::core::fmt::DisplayMock::fmt
        .next_call(matching!(_))
        .answers(&|_, f| write!(f, "mutation!"))
);

assert_eq!("mutation!", format!("{mocked}"));

answers的参数是一个具有与它模拟的方法相同签名的函数，包括self参数。

组合设置子句

Unimock::new()接受任何实现[子句]的类型作为参数。基本设置子句可以通过使用元组组合成复合子句。

#[unimock(api=FooMock)]
trait Foo {
    fn foo(&self, arg: i32) -> i32;
}

#[unimock(api=BarMock)]
trait Bar {
    fn bar(&self, arg: i32) -> i32;
}

fn test_me(deps: &(impl Foo + Bar), arg: i32) -> i32 {
    deps.bar(deps.foo(arg))
}

assert_eq!(
    42,
    test_me(
        &Unimock::new((
            FooMock::foo
                .some_call(matching!(_))
                .answers(&|_, arg| arg * 3),
            BarMock::bar
                .some_call(matching!((arg) if *arg > 20))
                .answers(&|_, arg| arg * 2),
        )),
        7
    )
);

// alternatively, define _stubs_ for each method.
// This is a nice way to group methods by introducing a closure scope:
assert_eq!(
    42,
    test_me(
        &Unimock::new((
            FooMock::foo.stub(|each| {
                each.call(matching!(1337)).returns(1024);
                each.call(matching!(_)).answers(&|_, arg| arg * 3);
            }),
            BarMock::bar.stub(|each| {
                each.call(matching!((arg) if *arg > 20)).answers(&|_, arg| arg * 2);
            }),
        )),
        7
    )
);

在这两个例子中，子句指定的顺序并不重要，除了输入匹配。为了使unimock找到正确的响应，调用模式将按照它们定义的顺序进行匹配。

交互验证

Unimock使用声明式方法执行交互验证。预期的交互在构建时配置，使用[子句]。Rust通过RAII和Unimock实现的[drop]方法使自动验证成为可能。当Unimock实例超出作用域时，Rust会自动运行其验证规则。

Unimock中始终启用一个验证

在某个设置子句中提到的每个MockFn都必须至少交互一次。

如果不符合此要求，Unimock将在其Drop实现中panic。这样做的原因是为了帮助避免测试代码中随着时间的推移积累“位退化”。在重构发布代码时，测试应该始终跟随，不要过于通用。

一般来说，子句不仅编码了允许发生的行为，而且也编码了这种行为必须发生。

调用模式中的可选调用计数期望

要为特定的调用模式设置调用计数期望，请查看Quantify或QuantifyReturnValue，它们有诸如once()、n_times(n)和at_least_times(n)等方法。

在放置了精确量化后，可以通过链式组合器构建输出序列验证。

each.call(matching!(_)).returns(1).n_times(2).then().returns(2);

输出序列将是[1, 1, 2, 2, 2, ..]。这种调用模式必须至少匹配3次。其中两次是因为第一个精确输出序列，然后至少一次是因为.then()组合器。

验证确切的调用序列

可以使用严格排序的子句来表示确切的调用序列。使用next_call来定义这种调用模式。

Unimock::new((
    FooMock::foo.next_call(matching!(3)).returns(5),
    BarMock::bar.next_call(matching!(8)).returns(7).n_times(2),
));

所有由next_call构建的子句都期望按照它们在子句元组中出现的顺序进行评估。

具有顺序敏感的子句和顺序不敏感的子句（如some_call）之间不会相互干扰。然而，这些类型的子句不能在一个Unimock值中组合使用，用于同一个MockFn。

应用程序架构

使用unimock编写大型、可测试的应用程序需要一定程度的架构纪律。我们已知如何使用特例边界来指定依赖项。但是，当涉及多个层次时，这在实际中能否扩展？unimock的一个主要特性是所有特例都由Unimock实现。这意味着特例边界可以组合，我们可以使用一个实现所有依赖项的值。

fn some_function(deps: &(impl A + B + C), arg: i32) {
    // ..
}

从某种意义上讲，这个函数类似于一个接收self的函数。`deps`参数是函数如何抽象其依赖项的方式。让我们保持这种调用约定，并通过引入两层使其稍微扩展一下。

use std::any::Any;

trait A {
    fn a(&self, arg: i32) -> i32;
}

trait B {
    fn b(&self, arg: i32) -> i32;
}

fn a(deps: &impl B, arg: i32) -> i32 {
    deps.b(arg) + 1
}

fn b(deps: &impl Any, arg: i32) -> i32 {
    arg + 1
}