FIX API 中的业务消息验证

问题描述 投票:0回答:1

我正在应用一种新的测试方法来验证 FIX 消息。

决定为每条消息创建每个测试用例,以验证字段中的有效、无效和格式错误的数据。我们同意将任何受支持的值范围定义为有效(非常明显),将无效定义为正确的数据类型但我们的系统不支持(例如,错误的精度、太长的字符串值或不支持的订单类型),并将格式错误定义为无效数据类型,违反 FIX 规范的值。

我面临着根据数据类型在多种行为上混合无效和格式错误的情况的问题。例如,无效的情况可能由执行报告(ExecType=Rejected)/CancelReplaceReject 和业务消息拒绝处理,格式错误的情况应该由会话拒绝处理。但是,有时在某些情况下,本应格式错误的内容会被视为无效,反之亦然。

我正在考虑添加不正确或不受支持的值维度。

我的项目的上下文是与连接的FIX引擎进行交换(匹配引擎),因为传入的业务消息可能会被FIX或匹配引擎验证规则拒绝。

如果您分享有关错误处理测试的任何想法或经验,我将非常感激。

automated-tests fix-protocol
1个回答
0
投票

不知怎的,对我来说听起来很复杂。

FIX 标签值语法中格式错误的字段定义如下:https://www.fixtrading.org/standards/tagvalue-online/#well-formed-field .

就我个人而言,我只是将所有可能的内容放入数据字典中,然后让验证完成其工作。其他情况(精度错误、不支持的订单类型等)应由您的应用程序逻辑处理,并以最具体的消息拒绝,例如ExecutionReport 作为对 NewOrderSingle 的回复,如果没有特定消息,则使用 BusinessMessageReject。

看这里: https://www.fixtrading.org/online-specification/business-area-infrastruct/#category-business-rejects

© www.soinside.com 2019 - 2024. All rights reserved.