Bouchonner des requêtes réseau facilement : OHHTTPStubs
AliGator
Membre, Modérateur
Hello all !
Juste pour vous informer que je viens de rendre publique une classe faite par votre serviteur qui permet de créer des bouchons de requête réseau.
C'est très pratique pour :
L'utilisation est simple : on indique un block qui sera appelé à chaque requête réseau, et qui vous donne l'occasion de retourner un objet OHHTTPStubsResponse pour indiquer la fausse réponse à utiliser (ou nil si vous voulez envoyer la vraie requête pour certains cas)
Le code le plus simpliste ressemble ainsi à cela :
OHHTTPStubs bypass toutes les requêtes réseau effectuées dans votre application, qu'elles soient faites avec ASIHTTPRequest, AFNetworking, NSURLConnection... donc c'est compatible quel que soit votre façon de faire vos requêtes dans votre appli !
Voilà , donc c'est partagé sur mon GITHub, n'hésitez pas à me dire si ça vous est utile !
Juste pour vous informer que je viens de rendre publique une classe faite par votre serviteur qui permet de créer des bouchons de requête réseau.
C'est très pratique pour :
- les tests unitaires (pour simuler des requêtes réseau valides ou invalides)
- le bouchonnage (utiliser des fichiers temporaires en attendant que le serveur ou le WebService avec qui vous communiquez soit fonctionnel)
- les tests de vitesse réseau, en simulant des requêtes lentes ou rapides (simuler un réseau EDGE, 3G, Wifi...) pour tester la réaction de votre application en conséquence
L'utilisation est simple : on indique un block qui sera appelé à chaque requête réseau, et qui vous donne l'occasion de retourner un objet OHHTTPStubsResponse pour indiquer la fausse réponse à utiliser (ou nil si vous voulez envoyer la vraie requête pour certains cas)
Le code le plus simpliste ressemble ainsi à cela :
[OHHTTPStubs addRequestHandler:^OHHTTPStubsResponse*(NSURLRequest *request, BOOL onlyCheck) {<br />
return [OHHTTPStubsResponse responseWithFile:@"response.json" contentType:@"text/json" responseTime:2.0];<br />
}];
Mais bien sûr, on peut faire ce que l'on veut dans le block, faire des tests en fonction de request.URL pour retourner un stub ou un autre, etc. créer un stub non pas avec un fichier mais avec des NSData (venant d'une image par exemple), etc... ou laisser la vraie requête s'exécuter aussi.OHHTTPStubs bypass toutes les requêtes réseau effectuées dans votre application, qu'elles soient faites avec ASIHTTPRequest, AFNetworking, NSURLConnection... donc c'est compatible quel que soit votre façon de faire vos requêtes dans votre appli !
Voilà , donc c'est partagé sur mon GITHub, n'hésitez pas à me dire si ça vous est utile !
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
C'est complémentaire à mon avis.
Là on se place en dehors du code à tester, au niveau du "tuyau" réseau.
On peut utiliser la classe pour faire du test unitaire mais aussi en cours de dévelopement pour remplacer un serveur ou simuler une série d'échange rapidement.
J'ai une question : peut-on utiliser la même technique sur OS X ?
Peut-on intercepter un protocol au niveau système ? (pour toutes les apps sur OS X, ou sur iOS jailbreaké)
Alors oui c'est complémentaire avec OCMock, et pas du tout concurrent. Un des buts est justement pour permettre de réaliser des tests unitaires (potentiellement avec OCUnit, OCMock & co) mais en permettant dans ces tests de bouchonner les requêtes réseau. Ce qui à ma connaissance n'est pas faisable simplement avec des outils comme OCMock justement. (Encore moins pour simuler une vraie requête avec un temps de latence).
Du coup pour certains tests unitaires de fonctionnalités qui en interne font des requêtes réseau, c'est bien pratique de pouvoir les intercepter au passage.
Et sinon hors du contexte de tests unitaires, c'est bien pratique pour pouvoir bouchonner une application simplement en attendant que la plateforme serveur sur laquelle on se base soit disponible (car bien souvent l'appli iPhone est développée en même temps que les WebServices qu'elle interroge, donc en attendant que ces derniers soient prêts...)
Sinon pour répondre à FKDEV je pense qu'il n'y a pas spécialement de contrainte à utiliser ça sous OSX. Je n'ai pas testé, mais le système de gestion réseau est le même normalement et je ne vois pas de classes ou autre qui en limiterait l'usage à iOS.
https://github.com/AFNetworking/AFNetworking/wiki/AFNetworking-FAQ
Sur la page de PortraitMatic, le lien du bas SoftwareEditorial.com paraà®t cassé!
J'obtiens:
Not Found
Github vient de rendre Open Source leurs API Octokit (utilisé par l'application Github pour Mac officielle)
Et guess what ? ils utilisent OHHTTPStubs.
Bravo Ali, tes classes ont la classe
Pour les intéressés : https://github.com/octokit/octokit.objc
Ah ouais, la classe Merci pour l'info JegnuX !!
À tes souhaits ! * tend un mouchoir en papier *
Avant, j'avais juste OHAttributedLabel qui a un succès fou sur la toile, qui est devenu un projet très connu des développeurs ObjC un peu partout (~1000 stargazers, c'est pas au point de AFNetworking, mais quand même très fortement référencé, utilisé par plein d'applis de divers calibres y compris Wunderlist ou SoundCloud ou plein d'autres, plein de sujets sur SO...).
Maintenant je commence à voir le même effet pour OHHTTPStubs, adopté de plus en plus par plein de projets (pour l'instant 270 stargazers c'est pas bcp mais déjà pas mal), cité par AFNetworking, utilisé dans le Kit GitHub, cité dans la prez qu'a fait le mec de CocoaControls, ...
Je vais p'tet commencer à les vendre, finalement, mes composants...