Test unitaire en background ?
Hello,
Je suis en pleine étude de tests unitaires sur Xcode. Et je me demande s'il existe pas un pluggin permettant de voir si les tests unitaires sont bon ou pas pendant qu'on est entrain de coder.
Pour parler plus simplement: "Est-ce que je suis entrain de casser le code ou pas ?".
ça existe dans le monde java ...
Est-ce que vous avez entendu parlé de cette fonctionalité sur Xcode ?
Merci pour vos retour.
K.
Mots clés:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je ne vois pas trop l'intérêt de ce plug-in ...
Il suffit de faire Command-U de temps en temps ...
Que fait de plus le plut-in Java ?
le pluggin java à un genre de voyant vert qui indique si les tests sont ok sinon c'est un voyant rouge.
C'est pratique si tu dois faire de l'audit de code et que tu as du code à cleanner ou du code mort à supprimer. (Bien sûr avant il faut s'assurer que les TU sont bien ecrit :-) )
K.
La solution à cela est donc l'intégration continue, qui va lancer tes tests unitaires automatiquement à chaque fois que tu commit
En fait, ce qui serait bien, ce serait que Xcode ne mette pas des plombes à lancer les tests U, mais ça paraà®t difficile étant donné qu'ils sont injectés dans le bundle de l'appli.
(Dans son bouquin, Kent Beck disait qu'il lançait les tests U en moyenne toutes les minutes, ça laisse rêveur).
ça c'est par défaut. Mais on peut aussi faire une cible Test en standalone, hors de l'appli.
D'ailleurs ça me saoule que Xcode configure les targets de test avec un TEST_HOST, je le supprime à chaque fois.
ça ne change pas que le lancement des tests unitaires prennent du temps car sont drivés par le lancement du simulateur pour les sandboxer. Mais au moins ça ne lance pas tout le chargement de l'application et le chargement du XIB de démarrage et le applicationDidFinishLaunching etc.
Presque pareil.
Pour les test unitaires, je fais ça en standalone.
Mais je garde une target de test dans l'application pour des tests de plus haut niveau. C'est un palliatif que j'ai trouvé à ma désespérante incompétence avec Automation : tant que je bricole quelques tests GUI tout roule, dès que je veux factoriser mes scripts de test pour en alléger la maintenance y'a tout qui pète.
Dès lundi je change notre template liftoff pour intégrer ça. Comme ça maintenant dès qu'on va créer un nouveau projet Xcode pour créer une nouvelle appli on n'aura plus des tests hosted mais que des standalone. Ca va éviter d'oublier de désactiver ce réglage par défaut à chaque fois et s'assurer que ça passe notre CI
Ce que vous dites est intéressant. Je ne m'étais pas posé la question. J'ai toujours besoin de tests exécutés au sein de l'application, mais je pourrais éventuellement créer une deuxième target de test.
De mon point de vue les tests exécutés au sein de l'application ne sont utiles que pour des tests d'interface (UI Tests, type Automation).
Pour tous le reste, normalement des Tests Fonctionnels séparés ne nécessitent aucunement de lancer l'application (ou alors c'est que ton architecture et découpage de ton code n'est pas assez découplé et trop dépendant de l'UI)
Peux-tu me donner un exemple d'un de tes tests unitaires qui pour toi nécessite qu'il soit exécuté au sein de l'application ?
Je suis entièrement d'accord avec toi. Comme je l'écrivais, c'est juste que je ne me suis pas posé de question.
Reste que mon contexte Core Data est créé par NSPersistentDocument, alors je me demande si ce sera bien facile de séparer les tests IHM des tests du Modèle.
Reste que je pense que c'est sans doute possible dans une certaine mesure ; de mon côté tous mes tests unitaires relatifs à CoreData sont isolés et utilisent un InMemoryStore et un MOC créé pour l'occasion le temps des tests là où ils utilisent un PersistantStore et un autre MOC dans la vraie app.
Oui, c'est ce que j'ai fait dans une autre appli, qui n'est pas basée sur NSDocument.
NSPersistentDocument est une sous-classe de NSDocument (donc une Contrôleur) mais maintient la stack Core Data (donc le modèle).
Pour avoir un MOC de test, j'instancie le NSPersistentDocument. Il y a un problème potentiel à ne pas l'injecter dans l'appli, parce que NSDocument ouvre un xib...
Et comme tu dis, c'est un problème lié à l'implémentation d'Apple.
Il faut simplement que je crée une nouvelle Target de test pour voir si ça pose réellement problème.
Bonsoir,
Je me permet relancer le sujets parce que j'ai trouvé des termes/concepts que je ne connaissait pas.
Comment ça ils sont injecté dans l'application ? Je pensais que les deux targets sont séparées avec deux bundles différents, non ?
@Aligator : Tu veux dire que tu supprimes cette clés des build settings ?
Y a aussi un truc dans Xcode que je ne comprends pas : Allow testing Host Application APIS. (YES|NO).( On le trouve dans la la target test/General).
Pour la target "standalone" : C'est quoi ? Si je mis le TEST_HOST à "" pour la target par défaut de Xcode, ai-je créé une target standalone ?
Je me suis amusé à mettre le TEST_HOST à "", mais de coup ça ne compile plus quand j'importe une classe de mon projet dans la target test ? J'imagine que la target test ne connais pas ces classes tout simplement.
​Et enfin, est-ce que vous avez deux targets séparées pour les tests unitaires et les tests fonctionnels ?
Merci pour vos réponses.
Super ! merci. Un travail impressionnant.
Comment je peux lancer mes tests unitaires "standalone" en ligne de commande svp ?
Cool merci. Bon week end tout le monde