• 0
    • 2
    • Not Needed
    • Not Needed
    • Hide

      1. What would you like to communicate to the user about this feature?
      2. Would you like the user to see examples of the syntax and/or executable code and its output?
      3. Which versions of the driver/connector does this apply to?

      Show
      1. What would you like to communicate to the user about this feature? 2. Would you like the user to see examples of the syntax and/or executable code and its output? 3. Which versions of the driver/connector does this apply to?

      Use Case

      As a Node driver engineer,
      I want our libmongocrypt c++ bindings to be tested,
      So that we can make changes safely.

      User Impact

      n/a, internal testing ticket.

      Dependencies

      • n/a

      Unknowns

      • How thoroughly do we want to test the bindings?  There are internal functions that can throw errors but these functions are not exported.  
        • These tests will only smoke test the exported API, primarily asserting on TypeErrors that we throw when we receive invalid options and that the classes have the expected structure.  We will not test private helper functions, or test statuses.
      • Do we want c++ tests or JS tests?  
        • JS, for simplicity and ease of integrating the tests into our existing test suite.
      • Should we add linting while we're here?  
        • We have clang-format installed as a dependency already and there is a clang-format file in the project root.  Additionally, we already have eslint setup.
      • Do we want to test memory management of the bindings?
        • This is out of scope of these tests but may be worthwhile in the future.

      Acceptance Criteria

      Implementation Requirements

      For the following tests, only validate errors that are thrown from our C++ bindings code (not libmongocrypt errors).

      • Add a JS test suite that tests the C++ bindings.
        • The test suite should run in everywhere `build-and-test-node` runs in CI.
        • MongoCrypt
          • Assert that there is a static property, libmongocryptVersion, on the MongoCrypt class. 
          • For each supported option, assert that the MongoCrypt constructor throws if the option is the incorrect type.
          • Assert that when passed valid options, it returns an MongoCrypt class.
          • Assert that the class has the expected methods and properties.
        • For each method on MongoCrypt, assert that they throw on invalid arguments (logic already in c++) and assert that they return instances of MongoCryptContext when passed valid arguments.
          • makeEncryptionContext(), makeExplicitEncryptionContext(), , makeDecryptionContext(), makeExplicitDecryptionContext(), makeDataKeyContext(), makeRewrapManyDataKeyContext
        • For a valid MongoCryptContext, confirm that it has the expected method and properties
          • nextMongoOperation(), addMongoOperationResponse(), finishMongoOperation(), nextKMSRequest(), provideKMSProviders(), finishKMSRequests(), finalize()
          • status, state
        • For a valid MongoCryptKMSRequest
          • confirm that it has the expected methods and properties
            • addResponse()
            • status, bytesNeeded, kmsProvider, endpoint, message
          • confirm that addResponse throws if it doesn't receive a buffer and confirm that it succeeds when passed a buffer.
      • Update the existing `index.test.ts` to assert that we do not export 
        MongoCryptContextCtor and MongoCryptKMSRequestCtor from the `index` file (they are export from C++).
      • linting (pending the unknowns section)
        • Add a linting task to the "Miscellanous" build variant in the evergreen config that runs `clang-format` and fails if there are lint changes needed.  This lint task should use the `.clang-format` file defined in the root of the repo.
        • Add a linting task to the "Miscellanous" build variant in the evergreen config that runs eslint on the Node directory and fails if eslint fails.

      Testing Requirements

      • (see implementation requirements)

      Documentation Requirements

      • Add testing documentation for developers in the README of the node bindings directory with instructions on how to build and run the tests.

      Follow Up Requirements

      • n/a

            Assignee:
            bailey.pearson@mongodb.com Bailey Pearson
            Reporter:
            bailey.pearson@mongodb.com Bailey Pearson
            Durran Jordan
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: