Jak testować jednostkę T-SQL
Jak testujesz jednostkowo swój T-SQL? Z jakich bibliotek/narzędzi korzystasz?
Jaki procent twojego kodu jest objęty testami jednostkowymi i jak to mierzysz?
Jak decydujesz, które moduły przetestować najpierw?
Czy uważasz, że czas i wysiłek włożony w testowanie jednostkowe opłaciły się, czy nie?
Jeśli nie używasz testów jednostkowych, czy możesz wyjaśnić dlaczego?
Nie znaleziono powiązanych wyników
Zaproszony:
Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się
5 odpowiedzi
Anonimowy użytkownik
Potwierdzenie od:
Jak testujesz jednostkowo swój T-SQL? Z jakich bibliotek/narzędzi korzystasz?
Spójrz na to
TSQLUnit
http://sourceforge.net/apps/trac/tsqlunit/
i to
tSQLt
http://tsqlt.org/
.
Eksperymentowałem z użyciem kilku różnych frameworków w wielu językach do testowania T-SQL, takich jak junit czy nunit. Powodem, dla którego wybrałem tę drogę, było skorzystanie z bogatych ram testowych w tych innych językach. Jeśli, na przykład, używasz nunit, ma on fajną linię poleceń i przeglądarkę GUI do przeglądania stanu twoich testów, a ponieważ używasz .net do pisania testów, bardzo łatwo łączy się z serwerem sql. JUnit ma dobrą integrację z wieloma komercyjnymi i open source'owymi IDE, takimi jak NetBeans i IDEA, a także sprawia, że testowanie T-SQL bardziej przypomina testowanie kodu Java, które jest bardzo bogate. Z drugiej strony nie tylko piszesz T-53, ale piszesz również w Javie lub .net, aby przetestować T-54.
Użyłem również Ruby z Rake (jak make lub ant) i wykonałem wywołania systemowe sqlcmd, aby wykonać skrypty sql, które z kolei zawierały testy. Skrypty zwracają wartości i ciągi z powrotem do ruby, aby przejść lub oblać test. Najbardziej podobało mi się to podejście, ponieważ było bardzo proste i łatwe dla innych. Inne ścieżki wymienione powyżej wymagały od programistów używania .net lub java, co w przypadku wszystkich typów administratorów baz danych może być trudne do pokonania, podczas gdy podejście ruby ze skryptami sql jest łatwiejsze do sprzedania z mojego doświadczenia. Typy DBA są generalnie open source i mogą łatwo czytać skrypty podobne do języka, podczas gdy Ruby ma niską krzywą uczenia się, a skrypty są łatwe w obsłudze w stosunku do klasy .net lub java.
Jaki procent twojego kodu jest objęty testami jednostkowymi i jak to mierzysz?
Prawdopodobnie tylko 20% tylko dlatego, że większość systemów baz danych w przeszłości nie miała testów zbudowanych dla nich w sposób, w jaki zostały zbudowane, więc jestem w trakcie dodawania testów z mocą wsteczną i dodawania testów w miarę pojawiania się nowych błędów i ulepszeń.
Czy uważasz, że czas i wysiłek włożony w testowanie jednostkowe opłaciły się, czy nie?
Baza danych to chleb powszedni większości firm. Moim zdaniem to zawsze się opłaca. Jeśli Twoja firma cierpi z powodu śmieci i wysokich współczynników odrzuceń dla klienta, prawdopodobnie żadne testy nie są tego warte, ponieważ nie są darmowe.
Jeśli nie używasz testów jednostkowych, czy możesz wyjaśnić dlaczego?
Z przyjemnością zobaczę, czy ktoś znajdzie odpowiedź na to pytanie, która nie jest absurdalna. Na przykład, dlaczego nie posadzić dziecka w foteliku samochodowym podczas jazdy po drodze… „są za drogie”… „umieszczenie dziecka w foteliku zajmuje zbyt dużo czasu”… ” jest bezpieczny bez niego „…” co może pójść źle, żeby to usprawiedliwić ”…„ po prostu nie ma wystarczająco dużo czasu ”.
Tak, wiem, może trochę ekstremalne, ale tak naprawdę, jeśli masz system i wnosi on wartość do firmy, należy go połączyć, aby pomóc wyłapać niektóre problemy, zanim staną się problemami produkcyjnymi. Testowanie jednostkowe nie jest panaceum, ale jest jednym z narzędzi, których potrzebujemy, aby zrobić wszystko, co w naszej mocy.
Powiedziałbym, że ogólnie rzecz biorąc, w ten czy inny sposób większość ludzi daje bazie danych darmową przepustkę, jeśli chodzi o testy strukturalne. Nie mam pojęcia, dlaczego tak się dzieje, ale widziałem to raz po raz. Bardzo chciałbym zobaczyć tę zmianę.
Anonimowy użytkownik
Potwierdzenie od:
DBFit
http://benilovj.github.com/dbfit
.
Nigdy nie znalazłem narzędzia do pomiaru pokrycia testami TSQL.
Zdając sobie sprawę, że pisanie testów jest trudne, odkryłem, że mogę poprawić jakość mojego kodu poprzez testy jednostkowe, gdy projekt był więcej niż trywialny.
Anonimowy użytkownik
Potwierdzenie od:
Nasz konkretny system jest prawie w całości zakodowany w T-SQL.
Jak testujesz jednostkowo swój T-SQL? Z jakich bibliotek/narzędzi korzystasz?
Znamy dobre wyniki, z którymi porównujemy. W naszych comiesięcznych analizach porównujemy miesiąc po miesiącu i przeprowadzamy cykl, aby zrozumieć wpływ zmian kodu i danych. Naszym głównym narzędziem jest zapisany proces, który porówna dwie tabele/widoki/podzbiory i dostrzeże różnice (z opcjami progów).
Jaki procent twojego kodu jest objęty testami jednostkowymi i jak to mierzysz?
Porównujemy dane generowane przez większość procesów z historycznymi zachowaniami. Kiedy wprowadzasz zmiany w kodzie, aby spełnić wymagania biznesowe, przeprowadzana jest analiza wpływu porównująca wyniki obu przebiegów. W dużym stopniu polegamy również na raportowaniu wyjątków, aby proaktywnie określić, kiedy dane nie spełniają oczekiwań/konfiguracji (ograniczenia w schemacie, jeśli to możliwe).
Czy uważasz, że czas i wysiłek włożony w testowanie jednostkowe opłaciły się, czy nie?
tak
Jeśli nie używasz testów jednostkowych, czy możesz wyjaśnić dlaczego?
Nasze testy jednostkowe odbywają się na każdym z naszych poziomów „procesu”. Każdy proces zwykle odpowiada jednej procedurze składowanej - więc jest to jednostka, którą testujemy. Porównanie wyników końcowych byłoby zgodne z testami systemowymi.
Anonimowy użytkownik
Potwierdzenie od:
Naszym celem jest zapewnienie 100% pokrycia naszych procedur składowanych. Dzięki temu możemy w razie potrzeby zmieniać podstawową strukturę i relacje tabeli, bez konieczności kompletnej aktualizacji oprogramowania (mamy niezależne zespoły zajmujące się przetwarzaniem danych i programowaniem). Nie zaczęliśmy jeszcze mierzyć pokrycia testów. Jesteśmy w trakcie opracowywania naszego pierwszego wdrożenia produkcyjnego z tym stosem technologii. Dla nas interfejsem między aplikacjami a danymi są procedury składowane. Najpierw tworzymy procedury składowane, które są wystarczające do zaspokojenia potrzeb zespołu aplikacyjnego, a następnie, gdy podpis jest na tyle stabilny, aby przejść do ciągłej integracji, tworzymy testy jednostkowe. Chcieliśmy zrobić TDD, ale mamy termin, który sprawia, że jest to po prostu niepraktyczne.
Nie mierzyliśmy zwrotu z inwestycji w wiązkę testową, ale doświadczenie pokazało nam, że zmiany w produkcyjnej bazie danych były bardzo kosztowne.
Anonimowy użytkownik
Potwierdzenie od:
Jak testujesz jednostkę T-35? Z jakich bibliotek/narzędzi korzystasz?
tSQLt 100%
Jaki procent twojego kodu jest objęty testami jednostkowymi i jak to mierzysz? Jak decydujesz, które moduły przetestować najpierw?
Niektóre projekty są w 100%, większość jest mniejsza :)
Napisałem narzędzie do pokrycia kodu T-SQL, które było sponsorowane przez redgate i zawarte w ich produkcie testowym sql:
https://github.com/GoEddie/SQLCover
https://github.com/GoEddie/SQLCover
Czy uważasz, że czas i wysiłek włożony w testowanie jednostkowe opłaciły się, czy nie?
Tak, w 100%, za każdym razem, gdy miałem testy, pomagało nam to działać szybciej. Za każdym razem, gdy nie było testów, to nas spowalniało.
Jeśli nie używasz testów jednostkowych, czy możesz wyjaśnić dlaczego?
Uważam za niewytłumaczalne, że ludzie nie testują jednostkowo swojego kodu :)