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
It is a standard practice of modern software development to perform functional testing of any application by running it against mock servers which emulate the backend services with which the application interacts. This allows negative path (error) responses from the backend service to be introduced and test that the application handles them correctly
In order to do this the Base URL used to interact with the Plivo API needs to be overridden. Since the Retrofit instance is private and there is no way replacing it, modifying the protected BASE_URL is the only way to achieve this with the helper library.
Unfortunately protected access means that the application code to override the base URL ends up looking like this:
// horrible hack using fake subclass to get around the lack of a formal method to override the base URL for testing
final String baseUrlOverride = System.getProperty("PLIVO_BASE_URL");
if( !Strings.isNullOrEmpty( baseUrlOverride)) {
LOGGER.info( "Overriding Plivo BASE_URL with '{}'", baseUrlOverride);
PlivoClient dummy = new PlivoClient( authId, authToken) {
{
PlivoClient.BASE_URL = baseUrlOverride;
}
};
}
plivoClient = Plivo.init( authId, authToken);
And worse, this is not test code, this is hack code inside the application itself.
Please extend PlivoClient to allow a cleaner way to override the BASE_URL for test environments.
The text was updated successfully, but these errors were encountered:
@jiffle Currently, we do not provide any mock servers to test APIs and to check responses. If you are trying to perform some unique test, please elaborate on the purpose of overriding the Base URL at run time so that we can check the same and help you accordingly.
I generally use wiremock to mock server responses for functional testing. This is just a REST API to your server so it's straightforward to mock standard responses.
But the high-level application development requirement that underlies this ticket is to be able to perform functional & acceptance application testing, ensuring that application correctly handles various scenarios - in particular negative path responses from services on which it depends.
My normal approach, and that of every team I've worked with in the last 7-8 years, is to e2e test the application using mocked upstream dependencies. Do you use a different approach to test these capabilities?
It is a standard practice of modern software development to perform functional testing of any application by running it against mock servers which emulate the backend services with which the application interacts. This allows negative path (error) responses from the backend service to be introduced and test that the application handles them correctly
In order to do this the Base URL used to interact with the Plivo API needs to be overridden. Since the Retrofit instance is private and there is no way replacing it, modifying the protected BASE_URL is the only way to achieve this with the helper library.
Unfortunately protected access means that the application code to override the base URL ends up looking like this:
And worse, this is not test code, this is hack code inside the application itself.
Please extend PlivoClient to allow a cleaner way to override the BASE_URL for test environments.
The text was updated successfully, but these errors were encountered: