对代理进行单元测试
Unit testing an agent
我正在尝试在 F# 中测试 MailboxProcessor。我想测试我给出的函数 f 在 post 发送消息时是否实际执行。
原始代码使用的是 Xunit，但我制作了一个可以使用 fsharpi 执行的 fsx。
到目前为止我正在这样做：
open System
open FSharp
open System.Threading
open System.Threading.Tasks
module MyModule =
type Agent<'a> = MailboxProcessor<'a>
let waitingFor timeOut (v:'a)=
let cts = new CancellationTokenSource(timeOut|> int)
let tcs = new TaskCompletionSource<'a>()
cts.Token.Register(fun (_) -> tcs.SetCanceled()) |> ignore
tcs ,Async.AwaitTask tcs.Task
type MyProcessor<'a>(f:'a->unit) =
let agent = Agent<'a>.Start(fun inbox ->
let rec loop() = async {
let! msg = inbox.Receive()
// some more complex should be used here
f msg
return! loop()
}
loop()
)
member this.Post(msg:'a) =
agent.Post msg
open MyModule
let myTest =
async {
let (tcs,waitingFor) = waitingFor 5000 0
let doThatWhenMessagepostedWithinAgent msg =
tcs.SetResult(msg)
let p = new MyProcessor<int>(doThatWhenMessagepostedWithinAgent)
p.Post 3
let! result = waitingFor
return result
}
myTest
|> Async.RunSynchronously
|> System.Console.WriteLine
//display 3 as expected
此代码有效，但我觉得不太好。
1) 在 f# 中 TaskCompletionSource 的使用是否正常，或者是否有一些专门的东西让我等待完成？
2) 我在 waitingFor 函数中使用第二个参数来限制它，我知道我可以使用类型 MyType<'a>() 来完成它，还有其他选择吗？我宁愿不使用我觉得很麻烦的新 MyType。
3) 除了这样做，还有其他方法可以测试我的代理吗？到目前为止，我唯一找到的关于这个主题的 post 是这篇 2009 年的博客post http://www.markhneedham.com/blog/2009/05/30/f-testing-asynchronous-calls-to-mailboxprocessor/
这是一个棘手的问题，我也已经尝试解决这个问题一段时间了。这是我到目前为止所发现的，评论太长了，但我也不愿意将其称为完整答案...
从最简单到最复杂，实际上取决于您想要测试的彻底程度，以及代理逻辑的复杂程度。
您的解决方案可能没问题
您所拥有的对于小型代理来说很好，它们的唯一作用是序列化对异步资源的访问，很少或没有内部状态处理。如果您像在示例中那样提供 f ，您可以非常确定它会在相对较短的几百毫秒超时内被调用。当然，它看起来很笨重，而且它是所有包装器和助手的代码大小的两倍，但是如果您测试更多代理 and/or 更多场景，它们可以重复使用，因此成本可以很快得到摊销。
我看到的问题是，如果您还想验证调用的函数以外的内容，它就不是很有用了——例如调用它后的内部代理状态。
一个注意事项也适用于响应的其他部分：我通常使用取消令牌启动代理，它使生产和测试生命周期都更容易。
使用代理回复渠道
在代理上添加 AsyncReplyChannel<'reply> to the message type and post messages using PostAndAsyncReply 而不是 Post 方法。它会将您的代理更改为如下所示：
type MyMessage<'a, 'b> = 'a * AsyncReplyChannel<'b>
type MyProcessor<'a, 'b>(f:'a->'b) =
// Using the MyMessage type here to simplify the signature
let agent = Agent<MyMessage<'a, 'b>>.Start(fun inbox ->
let rec loop() = async {
let! msg, replyChannel = inbox.Receive()
let! result = f msg
// Sending the result back to the original poster
replyChannel.Reply result
return! loop()
}
loop()
)
// Notice the type change, may be handled differently, depends on you
member this.Post(msg:'a): Async<'b> =
agent.PostAndAsyncReply(fun channel -> msg, channel)
这似乎是对代理 "interface" 的人为要求，但模拟方法调用很方便，测试也很简单 - 等待 PostAndAsyncReply（有超时），您可以去掉大部分测试助手代码。
由于您单独调用提供的函数和 replyChannel.Reply，响应还可以反映代理状态，而不仅仅是函数结果。
Black-box model-based 测试
这是我将要讨论的最详细的内容，因为我认为它是最笼统的。
如果代理封装了更复杂的行为，我发现跳过测试单个消息并使用 model-based 测试根据预期外部行为模型验证整个操作序列很方便。我为此使用 FsCheck.Experimental API：
在你的情况下，这是可行的，但没有多大意义，因为没有内部状态可以建模。为了给您一个例子，它在我的特定情况下看起来像什么，请考虑一个维护客户端 WebSocket 连接以将消息推送到客户端的代理。我不能分享整个代码，但界面看起来像这样
/// For simplicity, this adapts to the socket.Send method and makes it easy to mock
type MessageConsumer = ArraySegment<byte> -> Async<bool>
type Message =
/// Send payload to client and expect a result of the operation
| Send of ClientInfo * ArraySegment<byte> * AsyncReplyChannel<Result>
/// Client connects, remember it for future Send operations
| Subscribe of ClientInfo * MessageConsumer
/// Client disconnects
| Unsubscribe of ClientInfo
代理在内部维护一个 Map<ClientInfo, MessageConsumer>。
现在为了对此进行测试，我可以根据非正式规范对外部行为进行建模，例如："sending to a subscribed client may succeed or fail depending on the result of calling the MessageConsumer function" 和 "sending to an unsubscribed client shouldn't invoke any MessageConsumer"。所以我可以像这样定义类型来模拟代理。
type ConsumerType =
| SucceedingConsumer
| FailingConsumer
| ExceptionThrowingConsumer
type SubscriptionState =
| Subscribed of ConsumerType
| Unsubscribed
type AgentModel = Map<ClientInfo, SubscriptionState>
然后使用FsCheck.Experimental定义添加和删除具有不同成功消费者的客户端并尝试向它们发送数据的操作。 FsCheck 然后生成随机操作序列，并在每个步骤之间根据模型验证代理实现。
这确实需要一些额外的 "test only" 代码，并且在开始时会有很大的心理开销，但可以让您测试相对复杂的状态逻辑。我特别喜欢的是它可以帮助我测试整个合约，而不仅仅是单个 functions/methods/messages，就像 property-based/generative 测试帮助测试的不仅仅是一个值一样。
使用演员
我还没有走那么远，但我也听说过使用 Akka.NET 来支持 full-fledged actor 模型，并使用它的测试工具让您 运行 特殊测试上下文中的代理，验证预期的消息等等。正如我所说，我没有 first-hand 经验，但对于更复杂的状态逻辑（即使在单个机器上，而不是在分布式 multi-node actor 系统中）似乎是一个可行的选择。
我正在尝试在 F# 中测试 MailboxProcessor。我想测试我给出的函数 f 在 post 发送消息时是否实际执行。
原始代码使用的是 Xunit，但我制作了一个可以使用 fsharpi 执行的 fsx。
到目前为止我正在这样做：
open System
open FSharp
open System.Threading
open System.Threading.Tasks
module MyModule =
type Agent<'a> = MailboxProcessor<'a>
let waitingFor timeOut (v:'a)=
let cts = new CancellationTokenSource(timeOut|> int)
let tcs = new TaskCompletionSource<'a>()
cts.Token.Register(fun (_) -> tcs.SetCanceled()) |> ignore
tcs ,Async.AwaitTask tcs.Task
type MyProcessor<'a>(f:'a->unit) =
let agent = Agent<'a>.Start(fun inbox ->
let rec loop() = async {
let! msg = inbox.Receive()
// some more complex should be used here
f msg
return! loop()
}
loop()
)
member this.Post(msg:'a) =
agent.Post msg
open MyModule
let myTest =
async {
let (tcs,waitingFor) = waitingFor 5000 0
let doThatWhenMessagepostedWithinAgent msg =
tcs.SetResult(msg)
let p = new MyProcessor<int>(doThatWhenMessagepostedWithinAgent)
p.Post 3
let! result = waitingFor
return result
}
myTest
|> Async.RunSynchronously
|> System.Console.WriteLine
//display 3 as expected
此代码有效，但我觉得不太好。
1) 在 f# 中 TaskCompletionSource 的使用是否正常，或者是否有一些专门的东西让我等待完成？
2) 我在 waitingFor 函数中使用第二个参数来限制它，我知道我可以使用类型 MyType<'a>() 来完成它，还有其他选择吗？我宁愿不使用我觉得很麻烦的新 MyType。
3) 除了这样做，还有其他方法可以测试我的代理吗？到目前为止，我唯一找到的关于这个主题的 post 是这篇 2009 年的博客post http://www.markhneedham.com/blog/2009/05/30/f-testing-asynchronous-calls-to-mailboxprocessor/
这是一个棘手的问题，我也已经尝试解决这个问题一段时间了。这是我到目前为止所发现的，评论太长了，但我也不愿意将其称为完整答案...
从最简单到最复杂，实际上取决于您想要测试的彻底程度，以及代理逻辑的复杂程度。
您的解决方案可能没问题
您所拥有的对于小型代理来说很好，它们的唯一作用是序列化对异步资源的访问，很少或没有内部状态处理。如果您像在示例中那样提供 f ，您可以非常确定它会在相对较短的几百毫秒超时内被调用。当然，它看起来很笨重，而且它是所有包装器和助手的代码大小的两倍，但是如果您测试更多代理 and/or 更多场景，它们可以重复使用，因此成本可以很快得到摊销。
我看到的问题是，如果您还想验证调用的函数以外的内容，它就不是很有用了——例如调用它后的内部代理状态。
一个注意事项也适用于响应的其他部分：我通常使用取消令牌启动代理，它使生产和测试生命周期都更容易。
使用代理回复渠道
在代理上添加 AsyncReplyChannel<'reply> to the message type and post messages using PostAndAsyncReply 而不是 Post 方法。它会将您的代理更改为如下所示：
type MyMessage<'a, 'b> = 'a * AsyncReplyChannel<'b>
type MyProcessor<'a, 'b>(f:'a->'b) =
// Using the MyMessage type here to simplify the signature
let agent = Agent<MyMessage<'a, 'b>>.Start(fun inbox ->
let rec loop() = async {
let! msg, replyChannel = inbox.Receive()
let! result = f msg
// Sending the result back to the original poster
replyChannel.Reply result
return! loop()
}
loop()
)
// Notice the type change, may be handled differently, depends on you
member this.Post(msg:'a): Async<'b> =
agent.PostAndAsyncReply(fun channel -> msg, channel)
这似乎是对代理 "interface" 的人为要求，但模拟方法调用很方便，测试也很简单 - 等待 PostAndAsyncReply（有超时），您可以去掉大部分测试助手代码。
由于您单独调用提供的函数和 replyChannel.Reply，响应还可以反映代理状态，而不仅仅是函数结果。
Black-box model-based 测试
这是我将要讨论的最详细的内容，因为我认为它是最笼统的。
如果代理封装了更复杂的行为，我发现跳过测试单个消息并使用 model-based 测试根据预期外部行为模型验证整个操作序列很方便。我为此使用 FsCheck.Experimental API：
在你的情况下，这是可行的，但没有多大意义，因为没有内部状态可以建模。为了给您一个例子，它在我的特定情况下看起来像什么，请考虑一个维护客户端 WebSocket 连接以将消息推送到客户端的代理。我不能分享整个代码，但界面看起来像这样
/// For simplicity, this adapts to the socket.Send method and makes it easy to mock
type MessageConsumer = ArraySegment<byte> -> Async<bool>
type Message =
/// Send payload to client and expect a result of the operation
| Send of ClientInfo * ArraySegment<byte> * AsyncReplyChannel<Result>
/// Client connects, remember it for future Send operations
| Subscribe of ClientInfo * MessageConsumer
/// Client disconnects
| Unsubscribe of ClientInfo
代理在内部维护一个 Map<ClientInfo, MessageConsumer>。
现在为了对此进行测试，我可以根据非正式规范对外部行为进行建模，例如："sending to a subscribed client may succeed or fail depending on the result of calling the MessageConsumer function" 和 "sending to an unsubscribed client shouldn't invoke any MessageConsumer"。所以我可以像这样定义类型来模拟代理。
type ConsumerType =
| SucceedingConsumer
| FailingConsumer
| ExceptionThrowingConsumer
type SubscriptionState =
| Subscribed of ConsumerType
| Unsubscribed
type AgentModel = Map<ClientInfo, SubscriptionState>
然后使用FsCheck.Experimental定义添加和删除具有不同成功消费者的客户端并尝试向它们发送数据的操作。 FsCheck 然后生成随机操作序列，并在每个步骤之间根据模型验证代理实现。
这确实需要一些额外的 "test only" 代码，并且在开始时会有很大的心理开销，但可以让您测试相对复杂的状态逻辑。我特别喜欢的是它可以帮助我测试整个合约，而不仅仅是单个 functions/methods/messages，就像 property-based/generative 测试帮助测试的不仅仅是一个值一样。
使用演员
我还没有走那么远，但我也听说过使用 Akka.NET 来支持 full-fledged actor 模型，并使用它的测试工具让您 运行 特殊测试上下文中的代理，验证预期的消息等等。正如我所说，我没有 first-hand 经验，但对于更复杂的状态逻辑（即使在单个机器上，而不是在分布式 multi-node actor 系统中）似乎是一个可行的选择。