6

Szukam kilku dni na kilku forach, blogach, MSDN itp., Ale nie udało mi się znaleźć żadnych wskazówek na ten temat. Spróbuję wyjaśnić to stanowisko w bardziej szczegółowy sposób, ponieważ uważam, że informacje i dokumentacja rozwoju SSDT nie są dobrze udokumentowane i nie ma żadnego dokumentu dotyczącego najlepszych praktyk, takiego jak projekty bazy danych VS 2010 (http://vsdatabaseguide.codeplex.com/).Wskazówki na temat procesu rozwoju SSDT i najlepszych praktyk dotyczących zautomatyzowanych testów jednostek/integracji

Jestem programistą C# (bez DBA) i znajdujemy się na początku fazy rozwojowej projektu green field (10-15 programistów) i obecnie definiujemy nasz proces rozwoju, w tym obsługę tworzenia baz danych.

Technologia i narzędzie łańcuch chcemy użyć:

  • EF 5 (model pierwszy, może to zmienić do bazy po pierwsze dlatego, kwestie takie jak widoki, indeksy itp są dużo łatwiejsze w obsłudze)
  • (SQL Server Data Tools) SSDT
  • VS 2012/TFS 2012
  • MS testowe do zautomatyzowanego urządzenia/testy integracyjne

Proces rozwoju opiera się na Test-Driven Development i wygląda następująco:

  1. Każda funkcja została opracowana przez jednego programistę na oddzielnej gałęzi funkcji testów jednostkowych
  2. Opracowanie i wdrożenie (= implementacji funkcji)
  3. Jeśli funkcja wymaga dostępu do bazy danych, następnie programista musi do a) utworzyć/zaktualizować model EF b) utworzyć bazę danych localDB poprzez EF 'Wygeneruj bazę danych z modelu " c) utwórz/zaktualizuj projekt SSDT za pomocą schematu porównaj d) utwórz testy jednostkowe metodą inicjalizacji testu, która tworzy nowe dane podstawy i według danych testowych dla każdego testu
  4. scalania gałąź funkcji z powrotem do oddziału integracyjnego
  5. Po sprawdzeniu w scaleniu kompilacji CI wykonuje testy jednostka/integracja

Tak więc istnieje kilka punktów nie jestem 100% pewni jak je rozwiązać (zwłaszcza w bazie manipulacji z testów jednostkowych) i byłbym wdzięczny, jeśli można umieścić mnie w dobrym kierunku:

  1. Jak rozwiązać stworzenie bazy danych dla automatycznych testów jednostkowych:

    a) Wykonać skrypt generujący bazę danych SQL (który można ręcznie utworzyć wcześniej za pomocą funkcji publikowania SSDT) ​​dla każdej wykonanej metody testowej? Jest to opcja preferowana, ponieważ każdy test ma czysty i spójny stan bazy danych dla każdego testu. Czy występuje problem z wydajnością tworzenia bazy danych localdb dla każdego testu?

    b) Lub użyć zadania msbuild "SQLPublish" lub "sqlPackage.exe"? Myślę, że nie jest to możliwe, ponieważ byłaby to jednorazowa sprawa i chcę stworzyć nową testową bazę danych dla każdego testu jednostkowego.

    c) Czy można ręcznie utworzyć testową bazę danych i zapisać plik * .mdf w katalogu głównym kontrolnego folderu źródłowego i utworzyć kopię dla każdego testu?Ale nie wolałbym, ponieważ programista A mógłby przesłonić plik, który mógłby mieć zmiany od innego programisty B, który wcześniej sprawdzał swoje zmiany. A to oznacza, że ​​deweloper

  2. Jak rozwiązać tworzenie danych testowych dla zautomatyzowanych testów jednostkowych:

    a) wykonuje konkretny skrypt SQL testowy, który wstawia odpowiednie dane testowe dla każdego testu. Myślę, że oznacza to również stworzenie nowej bazy danych, o której mowa w punkcie 1. Ponownie jest to moja preferowana opcja.

    b) Lub używanie EF do tworzenia danych testowych wydaje się nie być czystym sposobem, ponieważ zależy to od implementacji modelu EF, które powinno być faktycznie testowane bezwarunkowo w testach jednostki funkcji.

    c) Lub użyj ręcznie utworzonych testowych plików baz danych. Ale to spowodowałoby, że proces tworzenia byłby bardziej skomplikowany dla programisty. A to może zostać przesłonięte przez innych deweloperów check in.

Może dobrze jest wspomnieć, czego oczekujemy od naszych testów jednostkowych do be.The celem naszych testów jednostkowych nie jest sprawdzenie schematu bazy danych, takich jak procedury przechowywane i tak dalej. Chcemy przetestować części naszych funkcji aplikacji za pomocą testów jednostkowych "kodu", które można również uznać za testy integracyjne.

Czy ktokolwiek z was ma podobny proces rozwoju i jakie są wasze doświadczenia? Wszelkie zalecenia dotyczące usprawnienia naszego procesu rozwoju? Czy są jakieś zasoby lub dokumenty dotyczące najlepszych praktyk dotyczące rozwoju SSDT? I najważniejsze pytanie dla mnie, w jaki sposób rozwiązałeś zautomatyzowane testy jednostkowe, w tym prawidłową obsługę baz danych i testy integracyjne?

+1

Początkowy instynkt - najpierw przejdź do DB, zamiast używać czystych modeli EF. Będziesz miał mniejszą szansę na "obiektową" strukturę tabeli w relacyjnej bazie danych. Jak długo DB bierze do całkowitego utworzenia od zera zależy od ilości danych, które ładujesz. W przypadku numeru 1 pochylam się w stronę litery "A", ale pamiętaj, że możesz zmienić instancję "Debugowanie" z (localdb) na rzeczywisty serwer SQL, jeśli chcesz. Możesz także opublikować nowy DB za każdym razem, jeśli przekroczysz. "C" to kiepski wybór. # 2 - Skłoniłbym się również do "A". Może zajrzeć do TSQLUnit lub podobnej opcji. –

+0

może to pytanie powinno zostać zadane na stronie programmers.stackexchange.org lub dba.stackexchange.org. Mało jest tam jednak oczu. – knb

+1

Mój pierwszy instynkt polega na tym, że powinieneś zatrudnić specjalistę od baz danych. Nie pozwoliłbym projektantowi bazy danych zaprojektować mojej aplikacji, iti jest nieodpowiedzialnym pozwolić projektantowi aplikacji zaprojektować bazę danych. I nigdy nie używaj EF rto deign bazy danych !!!!!!!!! – HLGEM

Odpowiedz

-1

Gdy potrzebujesz bazy danych, nie jest to test jednostkowy. W przypadku testów jednostkowych w połączeniu z frameworkami encji powinieneś użyć sfałszowanego kontekstu dbcontext.

+1

Nieprawda. SSDT zapewnia funkcję, która umożliwia prawdziwe testowanie jednostkowe modułów baz danych - funkcje i procedury przechowywane. Powinieneś się o tym dowiedzieć przed opublikowaniem złych odpowiedzi. –

+0

Funkcja testu jednostki SSDT nie może zainicjować bazy danych? –

Powiązane problemy