Astuces et didacticiels pour utiliser UISpec avec les données de l'API

Question

Je dois commencer à faire du TDD pour ce projet iPhone. Le problème est qu'il utilise les données API assez fortement.

Je suis à la recherche d'un bon tutoriel/guide/exemple de projet qui montre comment implémenter TDD comment configurer la base de données avant chaque test est exécuté pour l'iPhone. Je penche pour utiliser UISpec mais je suis prêt à regarder dans une autre suite de tests si cela fonctionne mieux. Le projet inclut déjà RestKit qui utilise UISpec pour ses propres tests, donc UISpec est déjà inclus dans le projet Xcode.

Answer 1

Je suis le développeur principal pour le projet RestKit et je recommanderais que vous pas utiliser UISpec pour vos tests. L'utilisation de UISpec par RestKit (plus précisément, une version hautement personnalisée) est un artefact du début du développement - j'utilisais UISpec pour les tests fonctionnels et hésitais à transporter autant de bibliothèques. Ces jours-ci UISpec est essentiellement abandonware et je suis passé à l'utilisation de KIF de Square pour mes tests d'interface utilisateur/fonctionnelle.

Pour les tests unitaires sur de nouveaux projets, j'aime Kiwi (https://github.com/allending/Kiwi) car il se trouve au-dessus du SenTestingKit intégré et fournit des tests de style RSpec. Cedar (https://github.com/pivotal/cedar) de Pivotal Labs et GHUnit (http://gabriel.github.com/gh-unit/) sont également solides. RestKit lui-même quittera probablement UISpec à un moment donné dans un proche avenir.

Maintenant, sur la question de savoir comment configurer la base de données pour vos tests. Si vous regardez dans les fichiers RKSpecEnvironment.h/m dans RestKit, il y a un tas de méthodes utiles pour le test unitaire. En supposant que vous utilisez l'intégration des données de base de RestKit, la méthode RKSpecNewManagedObjectStore() supprimera l'environnement des données de base et vous redéfinira avec une base de données claire en supprimant le stockage persistant.

Les tests unitaires de RestKit peuvent fournir de bonnes références (en plus des problèmes de harnais de test ci-dessus) sur la manière de se fondre sur les données API. La classe RKSpecResponseLoader est utile pour transformer des requêtes REST asynchrones en étapes procédurales (elle sert de délégué pour RKObjectLoader et fera tourner la boucle d'exécution pour attendre le chargement d'une requête) que vous pouvez tester. Le schéma général consiste donc à effacer l'état de la base de données, à configurer les objets dont vous avez besoin/à attendre, puis à effectuer une interaction avec l'API et à vous opposer aux résultats ou au nouvel état dans les données de base.