python, unittest: est-il un moyen de passer des options de ligne de commande pour l'application

J'ai un module qui importe unittest et a des cas de tests. Je voudrais
à accepter certaines options de ligne de commande (pour l'exemple ci-dessous, le nom d'un fichier de données),
mais quand j'essaie de passer l'option, je reçois le message "option -i n'est pas reconnu". Est-il possible d'avoir unittest + de fournir des options de l'application (note: je suis en utilisant optparse pour gérer les options)? Merci.

$ python test_app_data.py -i data_1.txt

option -i not recognized

=====================

de suivi: c'est une implémentation de la solution proposée:

import cfg_master  #has the optparse option-handling code

...

if __name__ == '__main__':    
    #add you app's options here...
    options_tpl = ('-i', '--in_dir', '-o', '--out_dir')
    del_lst = []
    for i,option in enumerate(sys.argv):
        if option in options_tpl:
            del_lst.append(i)
            del_lst.append(i+1)

    del_lst.reverse()
    for i in del_lst:
        del sys.argv[i]

    unittest.main()
  • En général, oui. Dans ce cas, la réponse semble dépendre beaucoup sur des détails qui ne vous ont pas donné.
  • Votre "suivi" doit être enregistrée comme une réponse à votre question ne devrait contenir que le ... bien ... question.
InformationsquelleAutor jd. | 2009-06-22
  1. 55

    Bâtiment sur Alex réponse, c'est en fait assez facile à faire en utilisant argparse:

    if __name__ == '__main__':
    parser = argparse.ArgumentParser()
    parser.add_argument('--input', default='My Input')
    parser.add_argument('filename', default='some_file.txt')
    parser.add_argument('unittest_args', nargs='*')

    args = parser.parse_args()
    # TODO: Go do something with args.input and args.filename

    # Now set the sys.argv to the unittest_args (leaving sys.argv[0] alone)
    sys.argv[1:] = args.unittest_args
    unittest.main()

    Je n'ai pas testé toutes les options que vous pouvez passer dans unittest pour voir si elles fonctionnent ou pas, mais faire passer des tests de noms fonctionne, par exemple:

    python test.py --input=foo data.txt MyTest

    S'exécute MyTest avec foo et data.txt.

    • Nice! Encore mieux, unittest.main() accepte un paramètre argv afin de ne pas avoir à jouer avec le global sys.argv, par exemple comme ceci: unit_argv = [sys.argv[0]] + args.unittest_args; unittest.main(argv=unit_argv)
    • Vous pouvez utiliser .parse_known_args() à la place et pas besoin d'utiliser un nargs='*' option; voir Python: exécuter un unittest.Cas de test sans appel unittest.main()? pour ma version.
    • J'ai fait un lien de cette réponse de la question référencé par @MartijnPieters, parce que l'approche fait appel à moi. Cependant, lorsque j'ai mis cette réponse n'a pas de travail pour moi lors du passage de drapeaux (--failfast et --catch), j'ai donc revenue à Martijn de réponse.
    • Où est args.unittest_args venant de
    • maintenant, je souhaite qu'il y ait une réponse facile comme ça pour pytest!
    InformationsquelleAutor tghw
  2. 32

    Dans votre if __name__ == '__main__': section, à laquelle vous n'êtes pas de nous montrer, vous aurez besoin de optparse et puis del sys.argv[1:] avant de passer le contrôle à unittest code, de sorte que le dernier code n'essayez pas d'interpréter vos options de ligne de commande nouveau lorsque vous avez déjà traité avec eux. (C'est un peu plus difficile à avoir quelques options de votre propre et également passer un peu de unittest, mais il peut être fait si vous avez de tels besoins complexes).

    • super, merci; juste pour confirmer: tout d'abord, permettez optparse pour gérer l' (éventuellement multiple et variable) des options d'application, puis de les supprimer à partir de sys.argv, et enfin permettre à unittest à prendre le dessus?
    • yep, c'est l'essentiel!
    • Génial, merci Alex! Je ne pouvais pas faire ce travail à tous 😛
    • mais que faites-vous si vous voulez passer des arguments à unittest.main()?
    • ensemble sys.argv exactement les arguments que vous voulez unittest.main pour analyser -- pas plus, pas moins.
    InformationsquelleAutor Alex Martelli
  3. 2

    J'ai pensé que je devais partager ma solution pour l'ajout d'un --commutateur de débogage pour le test de contrôle de l'enregistreur:

    if __name__=='__main__':
     parser = argparse.ArgumentParser(description="Build a compilation script")
     parser.add_argument('--debug', help='Turn on debug messages', action='store_true', default=False)

     args = parser.parse_args()

     if args.debug:
         log_level = logging.DEBUG
     else:
         log_level = logging.INFO

     logging.basicConfig(level=log_level)
     sys.argv.pop()
     unittest.main()

    Puis j'ai étendu unittest.TestCase pour ajouter de la journalisation:

     class mcs_TestCase(unittest.TestCase, object):
     def __init__(self, *args, **kwargs):
         super(mcs_TestCase,self).__init__(*args,**kwargs)
         logging.basicConfig()
         self.logger = logging.getLogger(__name__)
         ...

    Maintenant, je peux tourner et désactivez les messages dans mon test à l'aide de --debug, mais elle est ignorée régulièrement à des régressions.

    InformationsquelleAutor Ray Salemi
  4. 1

    Pour les petites applications autonomes, j'utilise une première sentinelle de l'option (-t) et d'appeler unittest.main() avant d'appeler argparse.ArgumentParser()

    if __name__ == "__main__":
    if len(sys.argv) > 1 and sys.argv[1] in ["-t", "--test"]:
        del(sys.argv[1])
        sys.exit(unittest.main()) # pass sys.argv[

    p = argparse.ArgumentParser()
    . . .
    InformationsquelleAutor qneill
  5. -6

    Vous ne devriez pas prendre des arguments et des options pour exécuter unittests, comme vous les faire exécuter en vertu de différent, de moins en moins prévisibles conditions de cette façon. Vous devez comprendre pourquoi vous avez besoin d'exécuter des tests avec des données différentes, et de vous faire de la suite de tests complète, assez pour couvrir le sol de tous les ensembles de données sans être exploitées de manière différente à chaque fois.

    • - je recevoir hebdomadaire des rapports de données (fichiers); je voudrais alimenter ces nouveaux rapports à la unittests, avant de générer les rapports publics. Si, pour une raison quelconque, la structure ou le type de la donnée a été modifiée (par exemple, un nouveau champ colonne a été ajoutée, une plage de données changé et un bug est dévoilé) je tiens à les attraper avec les tests. Espérons que cela a du sens.
    • sûr, mais c'est la validation des données, pas unittesting.
    • Que diriez-vous pour test conditionnel à sauter? Je lance tous mes cas de test en faisant unittest test de la découverte, mais il serait agréable d'être en mesure d'avoir des annotations sur certains tests comme @skipUnless ('plein' dans sys.argv) afin que je puisse avoir une simple ligne de commande de l'exécution de tous les tests, ou seulement certains.
    • Et si vous vous demandez pourquoi je peut vouloir le faire, que diriez-pour faciliter la séparation de rapides tests unitaires vs plus de régression ou de stress tests?
    • En tant que QA ingénieur de test, je suis d'accord avec ironfroggy est injustement modéré vers le bas réponse. Si vous êtes arrivés à une solution controversée à un problème - comme variable et argparse base de tests - c'est une bonne idée d'examiner à nouveau le problème pour voir si il y a de meilleures solutions. Par exemple, si vous voulez prendre "un test" et l'exécuter contre un énorme matrice de configuration de test, il y a des façons de le faire. Ces jours-ci (2015) il y a aussi "Py.test" qui est un départ de unittest et permet de faciliter la génération de cas de test des identifiants de données, à l'encontre d'une fonction de test. C'est moins passe-partout que unittest.
    • OIE - ne changer jamais de tests d'en faire de nouveaux. (Règle de pouce, n'est pas absolue, mais surtout ne jamais le faire)
    • Je comprends le sentiment et d'avertissement à propos de la Fpo idée conduisant à des problèmes potentiels. Mais ça, c'est comme un commentaire, et non pas comme une réponse. L'OP demande une solution à ses besoins, pas une critique sur la pertinence de ses besoins.

    InformationsquelleAutor ironfroggy