fichier test de persistance basé

Question

nous avons le code qui persiste un fichier et je voudrais vérifier le contenu du fichier au cours des essais. Je pensais que ce scénario sera mieux mis en œuvre si je fais abstraction de l'opération de persistance de fichiers à l'interface suivante:

public interface IFilePersist 
{ 
    void Save(XXX, FileLocation); 
} 

Dans les tests unitaires, je vais injecter la maquette qui va vérifier le contenu et dans la production de l'interface sera en fait persister au bon endroit.

Est-ce une tête? Cette pratique est-elle couramment utilisée? Pour DB opérations liées ce type d'opération est trivial et toujours utilisé.

Answer 1

Oui, c'est une façon de le faire, si vous voulez réduire les frais généraux de la création d'un objet simulé de suivi que vous pouvez également faire une commande locale de la méthode si possible. Je ne sais pas quelle langue que vous utilisez, mais en Java une priorité locale ressemblerait à ceci: « Salut »

// actual class 
public class SomeClass { 
    public void method() { 
     System.out.println("Hello!"); 
    } 
} 

// creating the class in test 

SomeClass c = new SomeClass() { 
public void method() { 
     System.out.println("Hi!"); 
    }  
}; 

Maintenant votre classe imprime réellement quand m() est appelée parce qu'elle est redéfinie dans une classe interne anonyme alors que la classe de production continue à imprimer "Hello!".

Answer 2

Oui, il est bon de garder des tests unitaires isolés du système de fichiers. D'abord parce que l'accès au système de fichiers est plus lent que l'accès à la mémoire. Alors on peut rencontrer d'autres problèmes (permissions, chemin manquant, FS complet ou non monté ...).

La vraie persistance, sur le système de fichiers, doivent être soumis aux tests d'intégration.