Comment utiliser le programme d'installation et de démontage en python unittest pour cette classe

Je vais avoir un moment difficile de l'apprentissage, développement piloté par les tests.

Je suis en train d'écrire une classe qui permettrait de prendre un nom de fichier ou de la description du fichier et la taille de l'entrée et de retour de la taille de segment de données à partir du fichier.

Tandis que de commencer avec les premiers tests tout ce que je pouvais trouver était de tester si les arguments passés n'étaient pas pas et de vérifier si les arguments sont valables fileobjects.

Tout ce que je pouvais trouver était de code ci-dessous, suis-je utiliser pour le montage et démontage des méthodes que je devrais le faire ou c'est complètement faux? Je suis entrain de créer un fichier temporaire et de l'instance de classe définie à lire dans le setUp() et je suis censé retirer l'objet d'une certaine manière dans tearDown()

Ci-dessous est le code

class Test_FileChunk(unittest.TestCase):
    """
    """
    def setUp(self):
        self.fhandle, self.fname = mkstemp()
        self.fc_obj = FileChunk(filename=self.fname)

    def tearDown(self):
        try:
            os.remove(self.fname)
        except OSError as oserr:
            print(oserr)

    def test_instance_variables(self):
        self.assertIsNotNone(self.fc_obj.filename)
        self.assertIsNone(self.fc_obj.filehandle)
        self.assertEqual(self.fc_obj.chunk_size, 8192)

    def test_check_if_instance_variables_are_valid_file_objects(self):
        handle = open(self.fc_obj.filename
        self.assertEqual(
            hasattr
                (handle, "r"), 'seek'), True,
                    msg="Is not a valid file object")
        handle.close()

Je suis passé par plusieurs TDD questions sur stackoverflow et a suggéré des tutoriels, mais encore il semble à la suite d'une TDD tutoriel est très intéressant mais en fait, TDD est très difficile. Je peux vraiment penser à ce que je veux faire dans ReadChunk classe mais juste ne peut pas obtenir ma tête autour de en effet de trouver les premiers essais et puis l'écriture du code. J'ai pu penser à vérifier si les valeurs passées sont objet de fichier valide par TDD, ce qui n'aurait pas eu lieu si je ont été codage sans TDD, mais je ne suis pas sûr si je suis en utilisant le unittest correctement. Ne peut pas obtenir la grande image. Quelqu'un pourrait s'il vous plaît suggérer comment aller à ce sujet et si le code ci-dessus ciselée est correct.

Je pense qu'il n'est pas nécessaire de suivre strictement TDD...
Je pense que c'est à lui de décider
assurez-vous

OriginalL'auteur anukalp | 2014-06-16

  1. 3

    Au sujet de votre code

    l'installation et le démontage sont facultatifs méthodes pour vous aider à installer et bien.. abattre l'environnement de test. Ils sont couramment utilisés pour, par exemple, créer et supprimer des dossiers temporaires de stockage de la sortie ou de l'installation d'un (raillé) de la base de données de la connexion pendant la phase de tests.

    Ils ne doivent pas être utilisés tester toutes les fonctionnalités. Si l'invocation de la FileChunk-objet ne devrait pas se produire dans l'installation. Dans chaque test, vous voulez tester certains cas, des méthodes de FileChunk, idéalement indépendamment les uns des autres. Par conséquent, vous devez appeler une nouvelle instance de FileChunk dans chaque nouveau cas. Donc dans ce cas dans les deux test_instance_variables et test_check_if_instance_variables_are_valid_file_objects.

    Environ TDD

    À utiliser pur TDD est une sorte de changement dans les mentalités. Il n'y a pas tout simple que des tutoriels afin de vous aider sur ce; que des livres entiers ont été écrits sur la façon d'utiliser le TDD.

    Cependant, je peux vous fournir quelques lignes directrices.

    1. Identifier l'interface publique de la classe. Le choix des méthodes des classes externes pouvoir l'utiliser? Ce qui devrait être l'entrée et ce qui devrait être la sortie de ces méthodes?
    2. Identifier les différents cas de la méthode. Quand devrait-elle sortie de vrai/faux? Quand faut-il lancer une exception?
    3. Écrire des cas de test basée sur les cas que vous avez trouvé dans 2.
    4. Écrire le plus de base de la classe factice pour FileChunk, qui, essentiellement, ne fait rien, mais ne avoir toutes les fonctionnalités de l'appareil-les tests sont des tests. De cette manière, tous les tests peuvent être effectués, même s'ils ne sont probablement voués à l'échec.
    5. Commencer à améliorer la FileChunk de classe jusqu'à ce que tous les tests passent.

    Un aspect important du TDD, à mon avis, est que vous ne pouvez pas commencer à faire des tests. Vous devriez vraiment savoir de quoi il devrait ressembler.

    OriginalL'auteur Erwin

  2. 1

    Contrairement à TemporaryFile(), l'utilisateur de mkstemp() est responsable de la suppression du fichier temporaire lorsque fait avec elle.
    - La Documentation Python

    donc supprimer le fichier dans le démontage est la bonne solution.

    Personnellement, je voudrais faire quelques test des fonctions comme

    def test_filename(self):
    self.assertEqual(self.fc_obj.filename, self.fname)
    self.assertIsTrue(os.path.isfile(self.fc_obj.filename))


def test_handle(self):
    self.assertIsNone(self.fc_obj.filehandle)

def open_file(self):
    # if you implemented an "open" method
    # you can use this method every time you test the opened file
    result = self.fc_obj.open()
    self.assertIsTrue(result, "File open failed")
    self.assertIsNotNone(self.fc_obj.filehandle)

# if you plan to implement a read and a write method you can add the following test
def test_read_write_file(self):
    self.open_file()
    random_data = ''.join(random.choice(string.ascii_uppercase + string.digits) for x in range(N))
    self.fc_obj.write(random_data)
    self.assertEqual(self.fc_obj.read(), random_data)

    et ainsi de suite et de définir un test pour tout ce que vous envisagez de mettre en œuvre, mettre en œuvre et à exécuter le test. Votre classe semble bon jusqu'à maintenant, mais comme vous pouvez le voir, vous devriez faire des tests concrets que vous pouvez utiliser, par exemple

    self.assertEqual(self.fc_obj.filename, self.fname)

    au lieu de 

    self.assertIsNotNone(self.fc_obj.filename)

    Si vous voulez beaucoup de test avec votre ouvert FileChunk objet, vous pouvez également ajouter un deuxième unittest.TestCase.

    class TestOpenFileChunk(unittest.TestCase);
    def setUp(self):
        self.fhandle, self.fname = mkstemp()
        self.fc_obj = FileChunk(filename=self.fname)
        self.fc_obj.open()

    def tearDown(self):
        # if you have this method
        self.fc_object.close()
        # and then
        try:
            os.remove(self.fname)
        except OSError as why:
            print(why)

    def test_read_write(self):
        #...

    Si vous souhaitez créer le FileChunk objet qu'une seule fois, vous pouvez également utiliser le setUpClass et tearDownClass méthodes.

    class TestOpenFileChunk(unittest.TestCase);
    @classmethod
    def setUpClass(cls):
        cls.fhandle, cls.fname = mkstemp()
        cls.fc_obj = FileChunk(filename=self.fname)
        cls.fc_obj.open()

    @classmethod
    def tearDownClass(cls):
        # if you have this method
        cls.fc_obj.close()
        # and then
        try:
            os.remove(cls.fname)
        except OSError as why:
            print(why)

    et l'utilisation de l'auto.fc_obj comme toujours dans les méthodes de test.

    dans setUpClass(), vous avez "l'auto", puis de l'appel par "cls", est-ce correct?. Je pense qu'il devrait "cls"

    OriginalL'auteur c0ff3m4kr