Testing parsing errors states that the schema for parseErrors is type-specific and defines how the field is interpreted for top-level documents and Decimal128.

DRIVERS-848 introduced the first parseErrors tests for Binary types (241ff38) and DRIVERS-1526 added additional tests (0a03c87).

I was surprised to see that the "string" field contains an extended JSON document. This means that these tests can only exercise the driver's extended JSON parser and cannot be used to test the code path for constructing a Binary BSON type directly. I realize that the spec changes in DRIVERS-848 pertain Extended JSON, but was it intentional to only test JSON parsing errors and ignore Binary BSON construction?

Note that parseErrors in top.json already tests invalid extended JSON for various BSON types, including Binary. IMO, the tests from DRIVERS-848 and DRIVERS-1526 would be better suited to that file.

In addition, I'd suggest replacing the parseErrors tests in binary.json with a different schema to allow drivers to test construction of a Binary BSON type. For example:

{
    "description": "UUID type requires 16 bytes",
    "data": "0123456789abcde",
    "subtype": 4
}

Here, I've replaced the singular string field with a data string field and subtype integer field. Alternatively, data could be defined as a base64 encoded string if we think we may need the ability express actual binary strings in parseErrors tests down the line.