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
sometimes just checking against canned responses (fixtures) is not good enough.
the main use case for integration testing is running the suite against the internal nightly build environment to detect problems (incompatible API changes, bad handling in the SDKs, etc) early.
one of the challenges in running integration tests is that many of the operations being tested require a specific state on the server. for example: starting an archive successfully requires that at least one client connection to the specific OpenTok session exists, deleting an archive requires an archive to exist, stopping an archive requires a started archive, etc.
one approach is to repurpose the unit tests to run in a different mode where they can hit live servers.
another approach could be scenario-driven, where a scripted set of operations are carried out sequentially. this could be better in address the challenge with server side state.
another technique that could be employed to address the server side state challenge is using a specific build of the client side opentok.js library that can run in node. the integration tests could "shell out" to a CLI that can conduct client side operations that will assist in setting up the proper state (like a client connection before starting an archive).
The text was updated successfully, but these errors were encountered:
sometimes just checking against canned responses (fixtures) is not good enough.
the main use case for integration testing is running the suite against the internal nightly build environment to detect problems (incompatible API changes, bad handling in the SDKs, etc) early.
one of the challenges in running integration tests is that many of the operations being tested require a specific state on the server. for example: starting an archive successfully requires that at least one client connection to the specific OpenTok session exists, deleting an archive requires an archive to exist, stopping an archive requires a started archive, etc.
one approach is to repurpose the unit tests to run in a different mode where they can hit live servers.
another approach could be scenario-driven, where a scripted set of operations are carried out sequentially. this could be better in address the challenge with server side state.
another technique that could be employed to address the server side state challenge is using a specific build of the client side opentok.js library that can run in node. the integration tests could "shell out" to a CLI that can conduct client side operations that will assist in setting up the proper state (like a client connection before starting an archive).
The text was updated successfully, but these errors were encountered: