Quel est un moyen facile de stub/dummy un service Web reposant?
Je souhaite créer une application Android. Cette application effectuera des appels RESTful vers un service Web pour obtenir des données.
Je sais ce que sera l'interface RESTful, mais je ne veux pas avoir le souci de créer ma propre implémentation. Existe-t-il un moyen simple de créer un service Web RESTful de talon qui renvoie des données statiques sans avoir à écrire une application WS complète pour cela?
La meilleure chose à faire est probablement de créer une maquette pour le service de service Web REST pendant que vous développez le code de votre application, puis de le remplacer par du code pour appeler le service Web réel qui renvoie des données "réelles" une fois que votre application est en cours. écrit.
J'écris actuellement une application très similaire à la vôtre qui (comme vous) obtient les données d'une application Web RESTful. Dans mon application, je suis le modèle MVP recommandé par GWT et est également documenté par Martin Fowler sous le nom PassiveView modèle.
Ce que vous voulez faire est d’abstraire le code pour que le service Web REST appelle une interface (le modèle). La responsabilité de cette classe de modèle est de fournir des données au présentateur/contrôleur. Le présentateur gérera toute votre logique métier, puis transmettra les données à la vue (la vue devrait également être assez stupide, ce qui permettra également de la simuler). Pendant les tests, vous allez créer un MockModel pour implémenter l'interface de modèle et transmettre les données de test à l'animateur, sans passer aucun appel de service Web! Ensuite, lorsque vous êtes prêt, vous allez remplacer cette classe par le service Web actuel et lancer les tests d'intégration.
Cette approche présente l’avantage supplémentaire de pouvoir créer facilement des scénarios de test spécifiques (et répétables) dans votre modèle fictif. Si vous n'avez pas le contrôle du service Web réel (et je suppose que vous n'en avez pas), cela peut être difficile (voire même impossible) à réaliser. Le résultat devrait être une application plus robuste et mieux testée, sans qu'il soit nécessaire de créer un test XML ou JSON ou de créer les services Web vous-même.
Mocky.io vous permet de créer des points de terminaison de stub et de spécifier les données qu’ils renvoient via des URL publiques.
Runscope (disclaimer, je suis un fondateur) vous permet de capturer une demande réelle une fois, puis de rejouer la réponse si nécessaire via - Lecture de réponses URL.
J'ai trouvé en utilisant Sinatra vraiment utile pour ce genre de chose si vous voulez tester le code d'appel HTTP réel. Vous pouvez avoir un point de terminaison renvoyant des données en quelques secondes. Très peu de connaissances sur Ruby requises.
require 'sinatra'
require 'json'
get '/Person' do
content_type :json
{ :id => 345, :key2 => 'John Doe' }.to_json
end
Est-ce tout ce dont vous auriez besoin pour retourner un objet JSON simple.
Une des approches (similaire à celle de Vinnie) consiste à implémenter localement votre service Web. Par exemple, votre service Web vous permet d’enregistrer un utilisateur et d’obtenir une liste d’utilisateurs en ligne.
L'interface webservice ressemble à ceci:
public interface WebService {
public LoginResponse login(String user, String pass) throws Exception;
public UsersOnlineResponse getOnlineUsers() throws Exception;
}
Ensuite, nous implémentons cette interface pour le service Web distant qui sera utilisé en production. L'implémentation à distance effectue des appels HTTP avec l'aide du client HTTP, récupère la réponse et l'analyse dans un objet de réponse approprié. En voici un fragment:
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;
}
}
À des fins de test, lorsque le service Web n'est pas disponible ou en cours de développement, nous mettons en place un service Web local. L'implémentation locale prend les réponses JSON prédéfinies du dossier des actifs et les analyse dans un objet de réponse approprié. C'est à vous de décider comment implémenter le comportement du service Web: cela peut être de simples réponses statiques ou des réponses aléatoires/dépendantes de la validation. Voici la partie de celui-ci:
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);
}
}
Ensuite, nous voulons basculer entre les implémentations sans douleur. L'utilisation des deux implémentations du service Web est transparente, car nous utilisons l'interface WebService. Nous allons donc configurer l'instance WebService au lancement de l'application. Application classe répond à nos besoins:
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();
}
}
Je suggère de vérifier WireMock (disclaimer - je l'ai écrit): http://wiremock.org/
Vous pouvez l'exécuter de manière autonome sur votre ordinateur portable, configurer des réponses abrégées et vérifier que votre application envoie les demandes que vous attendiez.
Il est configurable via une API Java ou JSON fluide (fichiers ou via HTTP).
Beeceptor (disclaimer, je suis l'auteur) vous aidera pour le cas d'utilisation exact ici. Créez un point de terminaison API, définissez un chemin fictif et une réponse. Utilisez-le dans des hackathons pour créer des fausses API en quelques secondes.
Beeceptor est plus qu'un service moqueur. C'est un proxy HTTP pour les API. Par exemple, si vous avez une vraie API, utilisez-la comme cible ultime. Beecetor intercepte le trafic et utilise des règles,
- lorsque les règles correspondent, les API sont moquées
- lorsqu'aucune règle ne correspond, votre point final cible est touché comme d'habitude.
Avec Mocky.io, vous aurez différents chemins d’API. Avec Beeceptor, votre URL de base sera identique tout le temps.
J'ai fini par écrire un outil de service fictif dans un but similaire: https://github.com/clafonta/Mockey/wiki
Un service factice est un excellent outil pour créer rapidement des interfaces utilisateur et valider votre code client, mais il peut devenir un véritable trou pour les lapins. Je vous recommande donc d'utiliser quelque chose qui existe déjà avant de créer votre propre. Github a beaucoup de résultats lorsque vous recherchez 'mock'. Indépendamment de ce que vous faites, voici quelques obstacles importants que vous pourriez rencontrer.
Vous finissez par travailler avec le mauvais format de données/JSON. Par exemple, votre application fonctionne très bien avec le service fictif, mais se bloque lorsque vous utilisez le service réel, car elle consomme un objet JSON, mais le service réel renvoie un tableau d'objets JSON. Pour éviter cela, vous pouvez utiliser JSON Schema pour mettre en évidence les modèles JSON non valides dans votre service fictif.
Votre application ne fait pas une demande valide. Votre service factice ne se souciera généralement pas de la demande entrante. Par exemple, le service réel a besoin d'un "ID client" et votre application ne le transmet jamais. Pour éviter cela, vous pouvez créer une logique de validation "paramètre requis" dans votre service fictif.
Tester les défis. Votre approche de tests fonctionnels automatisés doit interagir avec votre outil de service fictif si vous souhaitez tester des éléments allant au-delà du simple "chemin du bonheur". Par exemple, vous exécutez votre test "l'utilisateur A se connecte et voit 0 messages}" "contre" l'utilisateur B se connecte et voit 20 messages ".
Vous pouvez essayer Jadler ( http://jadler.net ). C'est une bibliothèque de stubbing/moqueur http sur laquelle je travaille depuis un certain temps. Je crois que cela devrait répondre à toutes vos exigences.
Atmo pourrait être utile.
Disclaimer: Je suis l'auteur de atmo.
Juste au cas où quelqu'un regarderait toujours ce fil à year >= 2017. Il existe un outil gratuit qui vous permet de créer des services Web factices et de repos en quelques secondes sans avoir à installer ou déployer quoi que ce soit sur votre ordinateur.
Vous pouvez sélectionner votre méthode http, le code de réponse, le corps du message de réponse, le type de contenu, spécifier un point de terminaison personnalisé, etc.
C'est très utile pour renvoyer des données factices de services Web distants à votre application, quel que soit son type d'application.
Déni de responsabilité, j'ai développé ce service par nécessité et je l’ai rendu gratuit afin que d’autres puissent en tirer parti.
Créez des fichiers avec des réponses factices et mettez-les dans un dossier. Maintenant, allez en ligne de commande et exécutez ce qui suit: Python -m SimpleHTTPServer
Vous pouvez maintenant accéder à ces fichiers et réponses factices à l'adresse Http: //: 8000
Je suggère de jeter un coup d'oeil à FakeRest ( https://github.com/marmelab/FakeRest ), un Fake Server uniquement côté client utilisant la correction de singe XMLHTTPRequest.
Avertissement: je l'ai écrit.