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:

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.


  • AliGatorAliGator Membre, Modérateur
    ça s'appelle le JIT Testing, ça n'existe pas sur Xcode et c'est pas plus mal car en général tu as besoin d'écrire pas mal de code dans ton app ou tes TU avant que ça repasse au vert donc autant le faire à  la main quand tu as fini ta feature.


    La solution à  cela est donc l'intégration continue, qui va lancer tes tests unitaires automatiquement à  chaque fois que tu commit
  • CéroceCéroce Membre, Modérateur

    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).




  • 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.




     


    ça c'est par défaut. Mais on peut aussi faire une cible Test en standalone, hors de l'appli.

  • AliGatorAliGator Membre, Modérateur
    février 2015 modifié #7
    Je ne lance jamais les Tests U en mode injectés dans l'application. D'autant que ça passe pas dans une CI.


    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.


  • D'ailleurs ça me saoule que Xcode configure les targets de test avec un TEST_HOST, je le supprime à  chaque fois.




     


     


    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.

  • AliGatorAliGator Membre, Modérateur
    L'outil "liftoff" vient d'implémenter la possibilité que j'avais suggéré de pouvoir configurer dans notre template Liftoff des Build Settings spécifiques pour les targets de test, en particulier pouvoir donc définir le TEST_HOST à  "".
    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 :)
  • CéroceCéroce Membre, Modérateur

    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.


  • AliGatorAliGator Membre, Modérateur

    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 ?


  • CéroceCéroce Membre, Modérateur

    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.


  • AliGatorAliGator Membre, Modérateur
    ça fait une éternité que j'ai pas développé pour OSX et j'ai cru comprendre que NSPersistantDocument n'était pas si facile à  découpler mais bon ça c'est un peu la faute d'Apple :-/


    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.
  • CéroceCéroce Membre, Modérateur
    février 2015 modifié #14

    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. 


     


    "Je ne lance jamais les test unitaires en mode injecté dans l'application"

     



     


     Comment ça ils sont injecté dans l'application ? Je pensais que les deux targets sont séparées avec deux bundles différents, non ? 


     


     


    D'ailleurs ça me saoule que Xcode configure les targets de test avec un TEST_HOST, je le supprime à  chaque fois.

     



    @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. 

  • AliGatorAliGator Membre, Modérateur
    mars 2015 modifié #16
    @samir plutôt que de me répéter ici, je t'invite à  aller lire mon article sur le sujet qui explique la différence entre test hostés et tests standalone.
  • Super ! merci. Un travail impressionnant. 


  • Comment je peux lancer mes tests unitaires "standalone" en ligne de commande svp ?  



    xcodebuild -target MyTargetTests -configuration Debug -sdk iphonesimulator
  • AliGatorAliGator Membre, Modérateur
    Tu n'as pas indiqué d'action en dernier argument lors de ton appel à  xcodebuild. Du coup il faut l'action par défaut, à  savoir l'action "build". Si tu veux qu'il fasse l'action test, faut rajouter l'action "test" à  la fin de la ligne de commande.
  • Cool merci. Bon week end tout le monde :)


Connectez-vous ou Inscrivez-vous pour répondre.