Comme le suggère rwwilden, la vie est beaucoup plus facile si vous utilisez une API basée sur les flux au lieu d'une API basée sur un nom de fichier. Utiliser la moquerie n'est pas très approprié ici, OMI; vous ne faites pas de "test de protocole" - vous voulez juste une source de données.
Vous pouvez également fournir une surcharge qui est une méthode simple utilitaire:
public Result ParseXml(string file)
{
using (Stream stream = File.OpenRead(file))
{
return ParseXml(stream);
}
}
Vous pouvez ensuite raisonnablement en toute sécurité pas test de cette méthode - il n'a pas de logique significative, après tout.
Maintenant, vous pourrait tester l'API basée sur les flux en utilisant une chaîne codée en dur dans votre code, puis en appelant Encoding.UTF8.GetBytes(xml)
et la construction d'un MemoryStream
autour du tableau d'octets résultant ... mais je préfère généralement utiliser des fichiers de données séparés dans mon projet de test. Définissez le type de contenu sur "ressource intégrée", puis utilisez Assembly.GetManifestResourceStream
pour obtenir un flux vers le fichier de test.
Si c'est vraiment un fichier XML normal, voulez-vous vraiment faire l'analyse vous-même? Y at-il une raison pour laquelle vous ne voulez pas laisser cela à l'infrastructure, et exprimer votre API soit en termes de l'API DOM, LINQ to XML, ou XmlReader
?
Pour quelqu'un d'autre confus sur la façon dont le chemin fonctionne ici, il semble être quelque chose comme ce qui suit: 'Your.Project.Name.SubFolder.FileName.extension'. – crush