如何在FluentAssertions中实现AllNotSatisfy条件断言

场景复现 #

测试使用的示例代码如下：

var ints = new List<Dictionary<string, string>>()
{
   new Dictionary<string, string>() { { "1", "bill" }, { "2", "john" } },
   new Dictionary<string, string>() { { "2", "jane" }, { "3", "alex" } }
};

以下代码可以正常编译：

ints.Should().AllSatisfy(x => x.ContainsKey("2"));

需要实现的需求是：验证集合内所有字典都不包含指定键（例如键"4"）。最初尝试的写法无法通过编译，抛出错误Only assignment, call, increment, decrement, await expression, and new object expressions can be used as a statement：

ints.Should().AllSatisfy(x => !x.ContainsKey("2"));

目前已知的可运行替代写法如下：

ints.Where(x => x.ContainsKey("2")).Should().BeEmpty();

符合框架惯用写法的实现 #

FluentAssertions 中AllSatisfy设计的核心用法是在传入的委托内，对每个元素执行链式断言，正确的否定断言写法如下：

ints.Should().AllSatisfy(x => x.Should().NotContainKey("4"));

这种写法是框架官方推荐的范式，相比Where过滤后判断集合为空的方式，断言失败时会精确标记集合中不符合规则的元素索引、具体的断言失败原因，错误信息的可读性高很多。

注意：之前能正常编译的ints.Should().AllSatisfy(x => x.ContainsKey("2"));是完全无效的断言——这行代码只是调用了ContainsKey方法，随后直接丢弃了布尔返回值，根本没有对结果做任何校验，哪怕所有字典都不含键"2"，这行代码也不会抛出异常，属于常见的误用坑。

编译错误与设计逻辑解释 #

编译报错的根源 #

该错误和FluentAssertions本身无关，是C#语法规则导致的：

• AllSatisfy的入参类型是Action<T>，要求传入的lambda体是可以作为独立语句执行的逻辑。
• x.ContainsKey("2")属于方法调用表达式，C#语法允许方法调用作为独立语句（自动忽略返回值），因此可以隐式转换为Action<T>，能通过编译。
• !x.ContainsKey("2")是带逻辑取反运算的布尔表达式，不属于C#规定的、可以单独作为语句使用的表达式类型，因此无法转换为Action<T>，直接编译失败。

为什么API设计为接收Action<T>而非返回布尔值的Func<T, bool> #

这种设计是为了匹配FluentAssertions的核心定位：

• 支持灵活的断言组合：Action入参允许在单个委托块内对元素编写任意数量、任意复杂度的断言规则，不需要局限于返回单个布尔结果，例如可以同时校验键存在性、值格式、集合长度等多个维度的规则。
• 保留完整的错误上下文：如果使用Func<T, bool>作为入参，断言失败时只能输出模糊的"元素不满足条件"提示；而使用Action嵌套框架自有断言的方式，可以输出精确到具体规则、实际值与预期值差异的错误信息，大幅降低调试成本。

内容的提问来源于stack exchange，提问作者Michael Wiles