Est-ce que je fais ces tests unitaires, n'est-ce pas?

Question

Je suis nouveau dans les tests unitaires pour mes propres projets, donc c'est ma première tentative d'écrire un test unitaire à partir de zéro. J'utilise python, et le module unittest. La classe TodoList testée ici est un wrapper pour les listes réelles, avec quelques méthodes supplémentaires pour des choses comme l'enregistrement sur disque. Il définit également quelques méthodes pour obtenir des éléments par leur ID dans la liste (ce qui n'est pas la même chose que l'index de la liste).

Tests (je l'ai découpé quelques méthodes d'aide, et un bon quelques tests pour des raisons de ne pas avoir des gens pour faire défiler toujours):

class TodoListTests(unittest.TestCase): 

    def setUp(self): 
     self.testdata = open("./testdata.json", "r") 
     self.testdata_text = self.testdata.read() 
     self.testdata.close() 

    def tearDown(self): 
     try: 
      os.remove("./todo.json") 
     except OSError: 
      # File not created, no need to delete. 
      pass 

    def create_todolist_and_safe_list(self): 
     self.create_data_file() 
     self.todolist = todolist.TodoList("./todo.json") 
     self.list = json.loads(self.testdata_text) 

    def create_data_file(self): 
     datafile = open("./todo.json", "w") 
     datafile.write(self.testdata_text) 
     datafile.close() 

    # Snip out a few more helper methods 

    def test_loop(self): 
     self.create_todolist_and_safe_list() 
     test_list = [] 
     for item in self.todolist: 
     test_list.append(item) 

     self.assertEquals(test_list, self.list) 


    def test_save(self):  
     self.create_todolist_and_safe_list() 
     self.todolist.save() 
     newfile_text = self.get_data_file_as_string() 
     self.assertEquals(newfile_text, self.testdata_text) 

    # Snip out the rest of the tests. 

Full link to source

Answer 1

Je pense que vous êtes aller dans le bon sens. Mais je vais envoyer quelques suggestions;

• Déplacer le self.testdata.close() de setUp() à la fonction tearDown().
• Entoure les autres d'ouvrir/fermer avec les blocs try/finally. Donc, si un fichier n'a pas ouvert avec succès, il sera fermé.

    try: 
     file.open() 
    finally: 
     file.close() 

• mieux organiser vos dossiers de test. Je vous suggère de créer un dossier nommé _tests et à l'intérieur de ce dossier, vous devriez mettre le module de tests (dans votre cas, vous n'avez qu'un seul module). Ensuite, pour chaque module, créez un dossier avec le nom du module et place les fichiers utilisés par les tests d'un module dans ce dossier.

Pour en savoir plus sur TDD et les tests que vous devriez lire le livre Test Driven Development: By Example

Answer 2

Non, il ne semble pas tout à fait comme vous. Les tests unitaires doivent être petits, rapides et simples. Effectuer des tests compliqués (tout ce qui repose sur une base de données externe, un système de fichiers, une configuration, un environnement ou tout autre élément en dehors du test et du code testé) est précieux, mais ne devrait pas faire partie de votre unité centrale tests ". Les tests unitaires doivent valider que le code suit la spécification. Un test devrait valider qu'avec l'entrée correcte, vous obtenez la sortie attendue. Un autre test unitaire devrait exister pour valider le comportement correct sur une entrée incorrecte. Cela se répète souvent pour différents types d'entrées correctes ou incorrectes, mais il y a généralement beaucoup plus de tests pour les entrées incorrectes que n'importe quoi. Pourtant, sans spécification, vous n'avez pas vraiment grand chose à tester. Le problème habituel est un manque de spécification technique (la spécification) qui vous indique ce qu'est une entrée correcte ou incorrecte et ce qu'il faut faire dans chaque cas. En plus du fait que vous utilisez le système de fichiers, vos tests semblent bons.