Obecnie zajmuję się "starym" systemem napisanym w C # .net, usuwając niektóre przestarzałe funkcje i dokonując pewnych refaktoryzacji. Dzięki Bogu, poprzedni facet napisał kilka testów jednostkowych (MSTests). Dość dobrze czuję się z testami JUnit, ale nie zrobiłem jeszcze wiele z MSTestami.

Metody testowe mają DeploymentItematrybut określający plik tekstowy, który jest analizowany przez testowaną metodę logiki biznesowej, oraz drugi, w DeploymentItemktórym określono tylko ścieżkę, zawierającą kilka plików TIF, które również muszą zostać wdrożone.

[TestMethod()]
[DeploymentItem(@"files\valid\valid_entries.txt")]
[DeploymentItem(@"files\tif\")]
public void ExistsTifTest()
{
   ...
}

Wcześniej testy działały, ale teraz musiałem zmienić nazwy plików TIF zawartych w katalogu \ files \ tif. Zgodnie z zasadą nazwy plików TIF muszą pasować do określonego wzorca, który jest również sprawdzany ExistsTifTest()metodą. Teraz musiałem zmienić nazwy plików, aby dostosować je do nowych wymagań i nagle pliki TIF nie są już wdrażane jak wcześniej.

Czy ktoś może mi podpowiedzieć, dlaczego tak się dzieje lub co może być tego przyczyną? To samo dzieje się również, gdy dodam nowy plik tekstowy, mówiąc „my2ndTest.txt” obok „valid_entries.txt” w katalogu \ files \ valid \ z odpowiednim atrybutem DeploymentItem w metodzie testowej. Plik nie został wdrożony?

Obrazy zostały już wdrożone, definiując ścieżkę wdrażania bezpośrednio w pliku testrunconfig, ale chciałbym zrozumieć, dlaczego takie rzeczy się zdarzają lub dlaczego, na przykład, mój nowy plik „my2ndTest.txt” nie jest wdrażany, podczas gdy inne.

DeploymentItem jest trochę bałaganu.

Każdy plik w rozwiązaniu będzie miał ustawienie „Kopiuj do folderu wyjściowego” w VS.NET. Musisz mieć ustawienie „Zawsze kopiuj” (lub podobne), aby pobrać pliki do folderu wyjściowego.

Sprawdź, czy masz ten zestaw dla nowych plików. Jeśli nie masz tego zestawu, pliki nie zostaną skopiowane do folderu wyjściowego, a następnie nie można ich wdrożyć z folderu wyjściowego do folderu, w którym MSTest to robi.

Osobiście, jeśli mam pliki, których potrzebuję do testów jednostkowych, stwierdziłem, że osadzanie tych plików jako zasobów w zestawie i samodzielne „rozpakowywanie” zestawu podczas testów jest bardziej przewidywalnym sposobem działania. YMMV.

Uwaga: Te komentarze są oparte na moich doświadczeniach z VS2010. Komentarze do mojej odpowiedzi sugerują, że nie jest to problem z VS2012. Wciąż trzymam się komentarzy, że używanie zasobów osadzonych wymaga mniej „magii” i, dla mnie, sprawia, że ​​etap „aranżacji” moich testów jednostkowych jest znacznie bardziej wyraźny.

W VS2010 mój Local.testsettings miał odznaczoną opcję „Włącz wdrażanie”, a atrybut DeploymentItem nie działał. Sprawdziłem to i wszystko działało dobrze. Mam nadzieję, że to pomoże!

Miałem również podobne problemy, ale znalazłem łatwe 3-stopniowe rozwiązanie tego problemu:

Zakładając, że struktura folderów wygląda następująco: SolutionFolder\ TestProjectFolder\ SubFolder\

1. Przejdź do „Solutions Items / Local.testsettings”> „Deployment”> zaznacz „Enable Deployment”
2. Jeśli używasz VS2010, upewnij się, że wszystkie pliki, które chcesz wdrożyć, mają właściwość „Kopiuj do folderu wyjściowego” ustawioną na „Kopiuj zawsze” lub „Kopiuj, jeśli nowszy”
3. Przypisz parametr TestMethod jedną z następujących opcji:
   • [DeploymentItem(@"TestProjectFolder\SubFolder")]aby wdrożyć całą zawartość w <SubFolder>katalogu Test Run
   • [DeploymentItem(@"TestProjectFolder\SubFolder", "TargetFolder")] wdrożyć całą zawartość <SubFolder>do <TargetFolder>w katalogu próbny

Ostatnia uwaga na temat MSTest (przynajmniej dla VS2010):

Jeśli chcesz, <TargetFolder>aby miało taką samą nazwę jak the <SubFolder>, użycie [DeploymentItem(@"SubFolder", @"SubFolder")]zakończy się niepowodzeniem, gdy biegacz MSTest trafi w głupi przypadek krawędzi. Dlatego należy poprzedzić <SubFolder>z <TestProjectFolder>jak tak:[DeploymentItem(@"TestProjectFolder\SubFolder", @"SubFolder")]

Miejmy nadzieję, że pomogę komuś innemu: wypróbowałem wszystkie sugestie tutaj i nadal mój element rozmieszczenia nie był kopiowany.

To, co musiałem zrobić ( zgodnie z sugestią tutaj ), to dodać drugi parametr do atrybutu DeploymentItem:

[DeploymentItem(@"UnitTestData\TestData.xml", "UnitTestData")]

Jeśli przejdziesz do pliku .testrunconfig i podczas wdrażania odznacz „Włącz wdrażanie”, testy będą działać w ich normalnej lokalizacji i wszystko będzie działać tak, jak w przypadku uruchamiania aplikacji poza testem jednostkowym.

Prawdopodobnie nie ma to związku z konkretnym problemem, ale oto kilka wskazówek, które znalazłem z atrybutem [DeploymentItem].

1. Kopiuj do katalogu wyjściowego należy ustawić na Zawsze kopiuj.

Robi nie działa, gdy używany z atrybutem [TestInitialize]

[TestInitialize]
[DeploymentItem("test.xlsx")]
public void Setup()
{

Powinien znajdować się na twoim [TestMethod], np

    [TestInitialize]
    public void Setup()
    {
        string spreadsheet = Path.GetFullPath("test.xlsx");
        Assert.IsTrue(File.Exists(spreadsheet));
        ...
    }

    [TestMethod]
    [DeploymentItem("test.xlsx")]
    public void ExcelQuestionParser_Reads_XmlElements()
    {
        ...
    }

Po wypróbowaniu wszystkich innych wymienionych tutaj sugestii nadal nie mogłem dowiedzieć się, co się dzieje. W końcu odkryłem, że w menu Test / Test Settings nie wybrano żadnego pliku ustawień, co oznaczało, że Wdrażanie nie było włączone. Kliknąłem opcję Test / Test Settings / Select Test Settings File, wybrałem plik Local.TestSettings i wszystko działało.

Nie jestem pewien, czy to dokładnie odpowiada na pytanie, ale może niektórym pomóc. Najpierw stwierdziłem, że pole „Włącz wdrożenie” musi być zaznaczone, aby wdrożenie działało. Po drugie, dokument mówi, że ścieżka źródłowa jest „względna w stosunku do ścieżki projektu”, co na początku oznaczało folder projektu. W rzeczywistości wydaje się, że odnosi się do folderu wyjściowego kompilacji. Więc jeśli mam folder projektu o nazwie `` TestFiles '' i plik w nim o nazwie Testdata.xml, użycie atrybutu w ten sposób nie działa:

[DeploymentItem(@"TestFiles\Testdata.xml")] 

Mogę oznaczyć Testdata.xmlplik Copy Always, aby kompilacja umieściła kopię w folderze wyjściowym (np Debug\TestFiles\TestData.xml.). Mechanizm wdrażania znajdzie wtedy kopię pliku znajdującą się w tej path ( TestFiles\Testdata.xml) względem wyniku kompilacji. Albo mogę ustawić atrybut w ten sposób:

[DeploymentItem(@"..\\..\TestFiles\Testdata.xml")] 

a mechanizm wdrażania znajdzie oryginalny plik. Więc albo działa, ale zauważyłem, że używając Copy Alwaysczasami napotykam ten sam problem, który mam podczas edycji pliku app.config w projekcie - jeśli nie zmienię kodu lub nie wymuszę przebudowy, nic nie uruchamia kopiowania plików oznaczonych do być kopiowane w kompilacji.

Najpierw wyłączono flagę wdrażania. Ale nawet po włączeniu tej funkcji z jakiegoś nieznanego powodu nic, nawet docelowy plik DLL, nie zostałoby skopiowane. Przypadkowo otworzyłem okno Test Run i zabiłem wszystkie poprzednie uruchomienia i magicznie znalazłem wszystkie biblioteki DLL i pliki, których potrzebowałem w folderze testowym przy następnym uruchomieniu ... Bardzo mylące.

Miałem ogromne problemy podczas próby udostępnienia plików - wypróbowałem wszystkie powyższe sugestie.

Następnie zamknąłem VS2010; uruchomiłem go ponownie, załadowałem rozwiązanie i wszystko działało. (!)

Sprawdziłem trochę; Po ustawieniu flagi „Włącz wdrożenie” na local.TestSetting nie należy po prostu ponownie uruchamiać testu z okna Wyniki testu. Musisz usunąć poprzednie uruchomienie testowe z interfejsu użytkownika, np. Uruchamiając inny test lub ponownie otwierając rozwiązanie.

Nie używaj DeploymentItem.

Jest bardzo trudny do poprawnej konfiguracji i nie działał z moim uruchomieniem testowym ReSharper ani natywnym dla MSTEST w Visual Studio 2017.

Zamiast tego kliknij prawym przyciskiem myszy plik danych i wybierz właściwości . Wybierz opcję Kopiuj do katalogu wyjściowego: zawsze .

Teraz w swoim teście zrób to. Katalog to po prostu katalog pliku odnoszący się do projektu testowego. Łatwo.

    [TestMethod()]
    public void ParseProductsTest()
    {
        // Arrange
        var file = @"Features\Products\Files\Workbook_2017.xlsx";
        var fileStream = File.Open(file, FileMode.Open);
        // etc.
    }

Wydaje się, że działa to dobrze w przypadku zautomatyzowanych systemów kompilacji i testowania.

Ponieważ atrybut DeploymentItem zawsze był dla mnie bałaganem, wdrażam takie pliki za pomocą skryptu po kompilacji. - Upewnij się, że pliki, które chcesz skopiować, mają ustawioną właściwość Zawsze kopiuj. - Zmodyfikuj skrypt po kompilacji projektu testowego, aby skopiować pliki z folderu docelowego kompilacji (Bin \ Debug) do lokalizacji, w której oczekuje ich test.

Wypróbuj to dla VS2010. Nie musisz więc dodawać DeployItems dla każdego tif.
Usuń rozszerzenie

[DeploymentItem(@"files\valid\valid_entries.txt")]  
[DeploymentItem(@"files\tif\")]  

Dodaj konfigurację testową.
- kliknij prawym przyciskiem myszy węzeł rozwiązania w eksploratorze rozwiązań
- Dodaj -> Nowy element ...
- Wybierz węzeł Ustawienia testu po lewej stronie, wybierz element po prawej stronie
- Kliknij Dodaj

Nazwij to np TDD

Wybierz TDDponiżej TestMenu> Edit Testsettings.

Kliknij Wdrożenie. Włącz go, a następnie dodaj żądane pliki i katalogi. Pojawi się ścieżka względna do rozwiązania. Pliki zostaną założone. Oryginalny plik jest na przykład tutaj:

D:\Users\Patrik\Documents\Visual Studio 2010\Projects\DCArrDate\WebMVCDCArrDate\Trunk\WebMVCDCArrDate\Authority.xml  

Kiedy uruchamiam mój test jednostkowy, jest on kopiowany do

D:\Users\Patrik\Documents\Visual Studio 2010\Projects\DCArrDate\WebMVCDCArrDate\Trunk\WebMVCDCArrDate.Tests\bin\Debug\TestResults\Patrik_HERKULES 2011-12-17 18_03_27\Authority.xml  

w kodzie testowym dzwonię z:

[TestMethod()]
public void Read_AuthorityFiles_And_ParseXML_To_Make_Dictonary()  
{  
  string authorityFile = "Authority.xml";  
  var Xmldoc = XDocument.Load(authorityFile);  

Nie ma potrzeby wybierania opcji Zawsze kopiuj; umieścić pliki w testproject; dodaj zakodowane na stałe ścieżki w kodzie testowym. U mnie to rozwiązanie sprawdziło się najlepiej. Próbowałem z DeploymentItem, kopiuj zawsze, ale nie podobało mi się.

Dla tych, którzy wolą uniknąć bałaganu DeploymentItem i zastosować podejście sugerowane przez @Martin Peck (zaakceptowana odpowiedź), możesz użyć następującego kodu, aby uzyskać dostęp do zawartości osadzonego zasobu:

public string GetEmbeddedResource(string fullyQulifiedResourceName)
{
    var assembly = Assembly.GetExecutingAssembly();
    // NOTE resourceName is of the format "Namespace.Class.File.extension";

    using (Stream stream = assembly.GetManifestResourceStream(fullyQulifiedResourceName))
    using (StreamReader reader = new StreamReader(stream))
    {
        string result = reader.ReadToEnd();
    }
}

Aby uzyskać szczegółowe informacje, zobacz ten wątek SO

Dla mnie główną przyczyną było coś zupełnie innego: kod produkcyjny wykonywany przez moje testy zmieniał nazwę i / lub usuwał wdrażany plik testowy .xml.

Dlatego, gdy uruchamiałbym moje testy indywidualnie, przeszłyby, ale podczas uruchamiania ich wszystkich razem, drugi i kolejny test kończyłby się niepowodzeniem z błędem „nie znaleziono pliku” (który pierwotnie błędnie zdiagnozowałem jako DeploymentItematrybut niedziałający).

Moje rozwiązanie polegało na tym, aby każda metoda testowa tworzyła kopię wdrożonego pliku (przy użyciu tej techniki ), a następnie testowany kod produkcyjny używał skopiowanego pliku zamiast oryginału.

Spędziliśmy dużo czasu, rozwiązując problem z elementami rozmieszczania w lokalnych rozgrywkach Unittest i Teamcity Unittest. To nie jest łatwe.

Bardzo dobrym narzędziem do debugowania tego problemu jest ProcessExplorer . Korzystając z eksploratora procesów, możesz sprawdzić, gdzie jest program Visual Studio wyszukujący elementy wdrożenia i wprowadzić poprawki w projekcie. Po prostu odfiltruj wszystkie operacje na plikach, w których ścieżka zawiera nazwę pliku elementu wdrożenia, a zobaczysz go.

Oprócz atrybutu Deployment, który należy sprawdzić, odkryłem jeszcze coś na temat atrybutu DeploymentItem.

[TestMethod()]
[DeploymentItem("folder\subfolder\deploymentFile.txt")]
public void TestMethod1()
{
   ...
}

Twój plik deploymentFile.txt musi być względny w stosunku do pliku rozwiązania, a nie do pliku testfile.cs.

Pracowałem nad tym w VS2013. Moje ustalenia, aby to działało:

• Kopiuj do katalogu wyjściowego należy ustawić na Kopiuj, jeśli nowsze / Kopiuj zawsze: OBOWIĄZKOWE.
• „Włącz wdrażanie” w .TestSettings: NIE WYMAGANE. Mam to działające bez pliku .TestSettings w ogóle.
• Określanie folderu jako drugiego parametru: OPCJONALNIE. Kształtuje układ folderu wyjściowego, działa dobrze bez.
• SPACES w nazwie pliku: przyprawiło mnie to o ból głowy - plik nigdy nie został skopiowany. Usunięcie spacji naprawiło ten problem. Nie zajrzałem jeszcze do postaci ucieczki.

Wskazówka, której też nauczyłem się na własnej skórze: nie zapomnij dodać tego atrybutu do każdego testu. Plik kopiuje się z pierwszego przypisanego testu w trakcie testu, ale nadal go brakowało, gdy kolejność testów uległa zmianie, a testy bez przypisania próbowały najpierw znaleźć plik.

Moją wielką łapą był sposób, w jaki DeploymentItem obsługuje katalogi. Używałem wersji z dwoma parametrami, w których oba były ścieżką katalogu zawierającą podkatalogi, które chciałem wdrożyć. Początkowo nie zdawałem sobie sprawy, że kopiuje tylko zawartość katalogu głównego, a nie całą rekursywną strukturę folderów!

Zasadniczo miałem [DeploymentItem (@ "Foo \", @ "Foo \")] i spodziewałem się, że wdroży mój Foo \ Bar. Specjalnie musiałem zmienić to na [DeploymentItem (@ "Foo \ Bar \", @ "Foo \ Bar \")] i teraz działa jak urok.

Ja też miałem podobne problemy. Mam wszystkie wymienione powyżej kroki, ale nadal nie mam szczęścia. Używam VS2010. Następnie stwierdziłem, że wybrano $ Menu> Test> Wybierz ustawienia aktywnego testu> Śledź i testuj wpływ . Zaczęło działać po zmianie śledzenia i przetestowaniu wpływu na lokalny . Ta strona zawiera bardzo przydatne informacje na temat kopiowania plików do folderu wyników testów. Czuję, że mogę dodać to doświadczenie.