You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Motivation
Testing an API client based on a third-party's continually-evolving API is challenging. It's made even more challenging by the fact that some API features (#38) are not available to all users. Setup/teardown may not be a viable concept for some more complex endpoints and is not necessarily sustainable. There are also no create endpoints for certain actions, such as creating schemas in the registry, precluding tests of many schema-requiring endpoints on a fresh environment.
Proposal A
There might be a possibility for soft tests that just check for syntax/types in an intercepted request's body. The V2 endpoints are variable in their finickiness, so this could take a while to get right, but would be a lightweight solution. If the underlying request-forming functions are appropriately strict, developing and testing on top of them would be much faster this way.
Proposal B
Fully mock the API with an implementation akin to moto, enabling a test workflow that could e.g. create, get, archive an object without having seen it before. The logic would still be equivalently tricky here. For example, in storage, matrix plates are created with capitalized wells, but are returned with lower-case wells.
The text was updated successfully, but these errors were encountered:
Motivation
Testing an API client based on a third-party's continually-evolving API is challenging. It's made even more challenging by the fact that some API features (#38) are not available to all users. Setup/teardown may not be a viable concept for some more complex endpoints and is not necessarily sustainable. There are also no create endpoints for certain actions, such as creating schemas in the registry, precluding tests of many schema-requiring endpoints on a fresh environment.
Proposal A
There might be a possibility for soft tests that just check for syntax/types in an intercepted request's body. The V2 endpoints are variable in their finickiness, so this could take a while to get right, but would be a lightweight solution. If the underlying request-forming functions are appropriately strict, developing and testing on top of them would be much faster this way.
Proposal B
Fully mock the API with an implementation akin to moto, enabling a test workflow that could e.g. create, get, archive an object without having seen it before. The logic would still be equivalently tricky here. For example, in storage, matrix plates are created with capitalized wells, but are returned with lower-case wells.
The text was updated successfully, but these errors were encountered: