android - publicidad - prototipo de envase

¿Cuál es una manera fácil de stub/dummy de un servicio web tranquilo?

Question

Quiero crear una aplicación para Android, esta aplicación realizará llamadas RESTful a un servicio web para obtener algunos datos.

Sé lo que será la interfaz RESTful, pero no quiero la molestia de crear mi propia implementación. ¿Existe una manera fácil de crear un servicio web RESTful stub que devolverá algunos datos estáticos sin tener que escribir una aplicación de WS completa para hacer esto?

Answer 1

Crea algunos archivos con respuestas ficticias y ponlos en una carpeta. Ahora ve a la línea de comandos y ejecuta lo siguiente: python -m SimpleHTTPServer

Ahora puede acceder a estos archivos y respuestas ficticias en http: //: 8000

Answer 2

En caso de que alguien todavía esté mirando este hilo en el year >= 2017 . Ahora hay una herramienta gratuita que le permite crear simuladores de jabón y servicios web de descanso en segundos sin la necesidad de instalar o implementar nada en su caja.

amock.io

Puede seleccionar su método http, código de respuesta, cuerpo del mensaje de respuesta, tipo de contenido, especificar punto final personalizado, etc.

Es muy útil para devolver datos falsos de servicios web remotos a su aplicación, cualquier tipo de aplicación.

Descargo de responsabilidad, desarrollé este servicio, por necesidad y lo hice libre para que otros puedan beneficiarse de la solución.

Answer 3

He descubierto que utilizar Sinatra realmente útil para este tipo de cosas si quieres probar el código de llamada HTTP real. Puede hacer que un punto extremo devuelva datos en segundos. Se requiere muy poco conocimiento de Ruby.

require ''sinatra''
require ''json''
get ''/Person'' do
content_type :json
{ :id => 345, :key2 => ''John Doe'' }.to_json
end

Es todo lo que necesitarías devolver un objeto json simple.

Answer 4

Probablemente, lo mejor que puede hacer es crear un simulacro para el servicio de REST mientras desarrolla el código de la aplicación y luego reemplazarlo con un código para llamar al servicio web real y devolver datos "reales", una vez que se haya escrito su solicitud.

Actualmente estoy escribiendo una aplicación muy similar a la tuya que (como tú) obtiene datos de una aplicación web RESTful. En mi aplicación, estoy siguiendo el patrón de MVP recomendado por GWT y también está documentado por Martin Fowler como el patrón de PassiveView .

Lo que desea hacer es abstraer el código para hacer que la llamada al servicio web REST se convierta en una interfaz (el Modelo). La responsabilidad de esta clase de modelo es proporcionar datos al Presentador / Controlador. El presentador manejará toda la lógica de su negocio y luego pasará los datos a la vista (la vista también debería ser bastante tonta, lo que también permite burlarla). Durante la prueba, creará un MockModel para implementar la interfaz del modelo y pasar los datos de prueba al presentador, ¡sin hacer una llamada de servicio web real en absoluto! Luego, cuando esté listo, reemplazará esta clase con el servicio web real y comenzará su prueba de integración.

Este enfoque tiene el beneficio adicional de que será fácil crear casos de prueba específicos (y repetibles) en su modelo simulado. Si no tiene el control del servicio web real (y asumo que no lo tiene), puede ser difícil (o incluso imposible) lograrlo. El resultado debería ser una aplicación más robusta y mejor probada sin necesidad de crear ninguna prueba XML o JSON o crear los servicios web usted mismo.

Answer 5

Puede hacer uso de http://maqueapp.com/ para crear el servicio web simulado. Es rápido y fácil. Me enteré en el episodio 157 de theflexshow (¡no en flexshow!)

Answer 6

Puedes probar Jadler ( http://jadler.net ). Es una biblioteca http stubbing / burla en la que he estado trabajando durante un tiempo. Debería cumplir con todos sus requisitos, creo.

Answer 7

Sugeriría ver WireMock (descargo de responsabilidad: lo escribí): http://wiremock.org/

Puede ejecutarlo de manera independiente en su computadora portátil, configurar las respuestas anotadas y verificar que su aplicación envíe las solicitudes que esperaba.

Se puede configurar mediante una API Java o JSON (archivos o HTTP) fluidos.

Answer 8

Sugiero echar un vistazo a FakeRest ( https://github.com/marmelab/FakeRest ), un servidor falso solo del lado del cliente usando parche de mono XMLHTTPRequest.

Descargo de responsabilidad: lo escribí.

Answer 9

Terminé escribiendo una herramienta de simulacro de servicio para un propósito similar: https://github.com/clafonta/Mockey/wiki

Un servicio simulado es una gran herramienta para construir rápidamente IU y validar tu código de cliente, pero puede convertirse en una madriguera, por lo que te recomiendo que uses algo que ya está disponible antes de construir el tuyo propio. Github tiene muchos resultados cuando buscas ''simulacro''. Independientemente de lo que haga, estos son algunos de los principales obstáculos que puede encontrar.

• Terminas trabajando con los datos incorrectos / formato JSON. Por ejemplo, su aplicación funciona muy bien con el servicio simulado, pero se interrumpe al acceder al servicio real porque su aplicación consume un objeto JSON pero el servicio real devuelve una matriz de objetos JSON. Para evitar esto, puede intentar usar el Esquema JSON para ayudar a resaltar modelos JSON no válidos en su servicio simulado.

• Tu aplicación no hace una solicitud válida. Su servicio de simulación no se preocupará por la solicitud entrante. Por ejemplo, el servicio real necesita un "ID de cliente" y su aplicación nunca lo transfiere. Para evitar esto, puede crear una lógica de validación de "parámetro de solicitud requerido" en su servicio simulado.

• Desafíos de prueba. Su enfoque de prueba funcional automatizada necesita interactuar con su herramienta de simulación de servicio si desea probar cosas más allá del simple "camino feliz". Por ejemplo, ejecuta su prueba " usuario A inicia sesión y ve 0 mensajes " frente a " usuario B inicia sesión y ve 20 mensajes ".

Answer 10

Uno de los enfoques (similar al de Vinnie) es realizar una implementación local de su servicio web. Por ejemplo, su servicio web le permite iniciar sesión en un usuario y obtener una lista de usuarios en línea.

La interfaz del servicio web se ve así:

public interface WebService {
public LoginResponse login(String user, String pass) throws Exception;
public UsersOnlineResponse getOnlineUsers() throws Exception;
}

Luego, implementamos esta interfaz para el servicio web remoto que se usará en producción. La implementación remota realiza llamadas HTTP con la ayuda del cliente HTTP, recupera la respuesta y la analiza en un objeto de respuesta apropiado. Aquí hay un fragmento de esto:

public class RemoteWebService implements WebService {
private AndroidHttpClient client = AndroidHttpClient.newInstance(USER_AGENT);
@Override
public LoginResponse login(String user, String pass) throws Exception {
LoginResponse response = client.execute(
createPostRequest(METHOD_LOGIN, user, pass),
new JsonResponseHandler(LoginResponse.class));
handleResponse(response); // verify response, throw exceptions if needed
return response;
}
}

Para fines de prueba, cuando el servicio web no está disponible o se está desarrollando, implementamos el servicio web local. La implementación local toma respuestas JSON predefinidas de la carpeta de activos y las analiza en un objeto de respuesta apropiado. Depende de usted cómo implementar el comportamiento del servicio web: puede tratarse de respuestas estáticas simples o algunas respuestas aleatorias / dependientes de la validación. Aquí está la parte de esto:

public class LocalWebService implements WebService {
private Context context;
public LocalWebService(Context context) {
this.context = context;
}
@Override
public LoginResponse login(String user, String pass) throws Exception {
Thread.sleep(DELAY); //emulate network delay
if (validateParams(user, pass)) {
return parseAssetsJson("ws/login.json", LoginResponse.class);
} else {
Response response = parseAssetsJson("ws/status_bad_request.json", Response.class);
throw new WebServiceException(response);
}
}
public <T> T parseAssetsJson(String filename, Class<T> klass) throws IOException {
InputStream is = context.getAssets().open(filename);
return JsonParser.getInstance().fromJson(new InputStreamReader(is), klass);
}
}

A continuación, queremos cambiar entre implementaciones sin dolor. El uso de ambas implementaciones del servicio web es transparente, porque usamos la interfaz WebService. Entonces, configuraremos la instancia de WebService en el lanzamiento de la aplicación. Application clase de Application adapta a nuestras necesidades:

public class App extends Application {
public static final boolean USE_LOCAL_WS = false;
private static WebService webService;
public static getWebService() {
return webService;
}
@Override
public void onCreate() {
super.onCreate();
webService = USE_LOCAL_WS ? new LocalWebService(this) : new RemoteWebService();
}
}

Answer 11

Mocky.io le permite crear puntos finales y especificar los datos que devuelven a través de las URL públicas.

Runscope (exención de responsabilidad, soy fundador) le permite capturar una solicitud real una vez, luego reproducir la respuesta según sea necesario a través de las URL de reproducción de respuesta .

Answer 12

Beeceptor (exención de responsabilidad, soy el autor) te ayudará con el caso de uso exacto aquí. Cree un punto final de API, defina una ruta y respuesta simuladas. Úselo en hackathons para construir API simuladas en segundos.

Beeceptor es más que un servicio de burla. Es un proxy HTTP para API. Por ejemplo, si tiene una API real, use la API real como objetivo final. Beecetor intercepta el tráfico y usa reglas,

• cuando se combinan las reglas, se burlan de las API
• cuando ninguna regla coincide, su punto final objetivo se golpea como de costumbre.

Con Mocky.io, deberás tener diferentes rutas API, con Beeceptor tu URL base siempre será la misma.

Answer 13

Atmo podría ser útil.

Descargo de responsabilidad: soy el autor de atmo.