Czy uważa się za „złą praktykę” sprawdzanie zawartości pliku / kodowania w testach jednostkowych?

84

Trochę kontekstu: Wcześniej musiałem zaktualizować kod SQL, który dostarczył inny mój kolega, a ponieważ jest to dość duży skrypt, jest on przechowywany jako osobny plik (który jest następnie odczytywany i uruchamiany w czasie wykonywania). Robiąc to, przez przypadek przywróciłem dwa błędy, które mieliśmy kilka miesięcy temu, a mianowicie:

Z jakiegokolwiek powodu plik ASCII został zakodowany w UTF-16 (kolega przesłał mi plik, który mógł go spowodować).
W skrypcie brakowało SETinstrukcji początkowych (wymaganych z powodu niektórych sterowników podczas produkcji, ale nie podczas czystej instalacji lokalnie).

Po debugowaniu tego przez około godzinę (ponownie) postanowiłem napisać kilka testów jednostkowych, aby upewnić się, że to się nigdy nie powtórzy (i podaj szybki sposób, aby to naprawić w komunikacie asercji, aby zapewnić łatwą poprawkę dla przyszłych programistów).

Kiedy jednak pchnąłem ten kod, podszedł do mnie inny kolega (który jest również naszym szefem zespołu) i powiedział, że nie powinienem robić tych rzeczy ponownie, ponieważ:

„Te rzeczy nie należą do testów jednostkowych”

„Testy jednostkowe powinny być używane tylko do sprawdzania przepływu kodu”

Jestem teraz dość skonfliktowany, ponieważ nadal uważam, że to, co robię, nie jest złe, ponieważ ten błąd nie zostanie ponownie wprowadzony w przyszłości, jednak ten kolega pracuje jako starszy i pod koniec dnia może zdecydować, co spędzamy czas na. Co powinienem zrobić? Czy mylę się, że robię to w ten sposób? Czy jest to uważane za złą praktykę?

unit-testing

— Paradoksy
źródło

7

Możliwy duplikat Czy należy napisać automatyczne testy, aby sprawdzić, czy dane są poprawne (zawartość plików konfiguracyjnych, baz danych itp.)?

— komara

35

„ Testy jednostkowe powinny być używane tylko do sprawdzania przepływu kodu ” Powiedziałbym, że to bzdury. Tradycyjnie powinny one obejmować wszystkie testy niezbędne do zapewnienia, że „jednostka” rozpatrywana osobno jest poprawna. Jeśli napiszesz tylko te testy jednostkowe, które są przydatne do „sprawdzenia przepływu”, cokolwiek to znaczy, mam nadzieję, że masz także osobne obszerne pakiety testowe (napisane przez dział kontroli jakości?).

— gbr

8

Problem twojego kolegi i tak jest prawdopodobnie tam, gdzie poddajesz się tym testom. Skupiłbym się na tym, pomijając dyskusje na temat denominacji / świętych wojen. Możliwe, że testy te są zbyt wolne dla pakietu, do którego je dodałeś, ale jest również całkiem możliwe, że twój kolega jest skupiony na swoim pomyśle na testach jednostkowych i robi problem z nieistniejącego problemu; więc lepiej najpierw wyjaśnić, na czym polega prawdziwy problem.

— gbr

2

Nawiasem mówiąc, te testy wyglądają jak coś, co chcesz uruchomić za każdym razem, gdy modyfikujesz ten plik SQL. Tutaj głównym problemem mogą być narzędzia testujące, które mogą nie obsługiwać trybu działania „tylko w przypadku modyfikacji”; co powoduje rzeczywiste, konkretne problemy, warto włączyć ręcznie funkcję „tylko jeśli zmodyfikowano” z pewną kludge tylko dla tych konkretnych testów.

— gbr

5

Zamiast sprawdzać, czy plik ma poprawną zawartość i kodowanie, dlaczego nie przetestować, czy działa ?

— immibis

156

Najprawdopodobniej napisane przez ciebie testy są bliższe testom integracji lub regresji niż testom jednostkowym. Chociaż linia może być bardzo rozmyta i czasami przechodzi w pedanterię nad tym, co jest testem jednostkowym, ale nie wrócę do twojego kolegi i zapytam, gdzie powinny być napisane testy, ponieważ zapewniają one wartość dodaną, zapewniając poprawność kodu.

Nie skupiałbym się zbytnio na tym, co jest testem jednostkowym, a czym nie jest, i zdałem sobie sprawę, że nawet jeśli jest to test integracyjny, w teście może być jeszcze wartość.

— RubberChickenLeader
źródło

Komentarze nie są przeznaczone do rozszerzonej dyskusji; ta rozmowa została przeniesiona do czatu .

— Thomas Owens

36

Z technicznego punktu widzenia nie jest to test jednostkowy, a raczej etap weryfikacji. Właściwe podejście naprawdę zależy od przepływu pracy. Kierownik zespołu ma rację co do celu testów jednostkowych. Mam wrażenie, że jest to przypadek użycia niewłaściwego narzędzia do pracy, która wciąż musi zostać wykonana. Zacznij od tego:

Jaki problem próbuję rozwiązać?

Przy opisie musisz sprawdzić, czy wszystkie skrypty bazy danych są zgodne z niektórymi standardami.

Jakie narzędzia / procesy są dostępne, aby rozwiązać problem?

Jakość kodu źródłowego jest zwykle sprawdzana za pomocą narzędzi do analizy statycznej . Jeśli nie masz narzędzia do analizy statycznej do sprawdzania poprawności kodu SQL, możesz utworzyć szybkie i brudne narzędzie, które sprawdza wszystkie przekazane do niego pliki SQL. Nie zaszkodzi sprawdzić, czy istnieją narzędzia analizy statycznej, które poradzą sobie z problemami, o których mówisz.

Jeśli utworzysz tę część infrastruktury kompilacji, taką jak włączenie jej do Jenkins lub coś w tym rodzaju, można ją zastosować do wszystkich plików SQL w projekcie.

Testy jednostkowe rozwiązują problem tylko dla bieżącego pliku.

Jak zgłosić potrzebę użycia narzędzia?

To całkiem proste, rozmawiasz z liderem zespołu. Może on współpracować z właścicielem produktu, a ty w celu ustalenia ryzyka / nagrody za inwestowanie w oprzyrządowanie. Jeśli jest to prawdopodobnie problem jednorazowy, oprzyrządowanie prawdopodobnie byłoby nadmierne. Jeśli oprzyrządowanie do wychwytywania największych problemów jest łatwe, może być warto tylko do kontroli poczytalności.

Twój lider zespołu może mieć pewne pomysły, których ty (lub ja) nie wziąłem pod uwagę, które mogą lepiej rozwiązać problem.

— Berin Loritsch
źródło

21

Przy omawianiu kosztów i ryzyka należy pamiętać, że spowodowało to stratę czasu z powodu ponownego wprowadzenia wcześniej rozwiązanych błędów. Samo to stanowi silny argument zautomatyzowania weryfikacji. +1

— jpmc26

1

@ jpmc26, całkowicie się zgadzam. Dyskusja powinna rozpocząć się od tego, że straciłeś tyle godzin, aby dowiedzieć się, co było nie tak, a testy jednostkowe były Twoją pierwszą próbą zapobieżenia utracie tego samego czasu przez resztę zespołu. Jednak praca z liderem zespołu, który musi odpowiadać kierownictwu i interesariuszom, jest zwykle bardzo doceniana. Jako lider zespołu chcę być w stanie bronić zarządzanych przez nas narzędzi / praktyk / kodu. Gdybym zobaczył testy jednostkowe, których nie można prześledzić do rzeczywistych wymagań, również bym się tym przejmował.

— Berin Loritsch

1

@BerinLoritsch Technicznie rzecz biorąc, nie jest to test jednostkowy. Naprawdę chciałbym wiedzieć, na jakiej „technice” opieracie to twierdzenie. O ile mi wiadomo, nie ma jednej wiarygodnej definicji testów jednostkowych i wszyscy mają własne wyobrażenie o tym, czym są .

— gbr

2

@gbr Deweloperzy nieformalnie zgadzają się, że testy jednostkowe to testy przeprowadzane w oderwaniu od systemów zewnętrznych. Testują tylko sam kod, a nie interakcje z plikami, bazami danych lub innymi usługami zewnętrznymi. Wikipedia dokumentuje to zrozumienie: en.wikipedia.org/wiki/Unit_testing#External_work .

— jpmc26

1

@BerinLoritsch Możliwe jest również, że wszyscy interpretujemy pytanie w inny sposób, w każdym razie nie było ono zbyt szczegółowe i autor jeszcze do nikogo nie wrócił. Zresztą nie jestem bardzo zainteresowany dalszą dyskusją na temat klasyfikacji tych testów, ważne jest, czy powinny one istnieć (jestem pewien, że powinny) i jak często je uruchamiać (przy każdej zmianie IDE, przy każdym zatwierdzenie lokalne, za każdym razem, gdy pchasz się do centralnego repozytorium, za każdym razem ...).

— gbr

19

Złą praktyką jest nazywanie testów dostępu do plików „Testami jednostkowymi”.

On: „Te rzeczy nie należą do testów jednostkowych”

Ty: „Ma sens, ale nie mogłem znaleźć lepszego miejsca na ich umieszczenie. Gdzie oni należą?”

Niestety, jakie rodzaje testów istnieją i jak są zorganizowane, są całkowicie zależne od firmy. Musisz więc dowiedzieć się, jak Twoja firma obsługuje te testy.

Jeśli nie masz jeszcze sposobu na uruchomienie automatycznych testów innych niż testy jednostkowe, pragmatyczne podejście polega na oznaczeniu testów jednostkowych, które tak naprawdę nie są testami jednostkowymi, do momentu, gdy będziesz mieć ich wystarczająco dużo, aby dowiedzieć się, jaki rodzaj testy, które faktycznie masz / potrzebujesz. Następnie możesz zacząć organizować.

— Piotr
źródło

2

Złą praktyką jest nazywanie testów dostępu do plików „Testami jednostkowymi”. Tutaj dostępny plik jest plikiem źródłowym . Będzie on dostępny tak samo, jak każdy plik źródłowy (w celu jego przeanalizowania). Fakt, że test prawdopodobnie nie zostanie wykonany w tym samym języku sprawdzanej „jednostki” (SQL), czyni go niekonwencjonalnym, ale nie powinien wpływać na jego klasyfikację jako testu jednostkowego. trwa ...

— gbr

1

... Właściwie prawidłowe kodowanie pliku to „test”, który jest wykonywany przez dowolny kompilator za każdym razem, gdy czyta plik źródłowy. Problem polega na tym, że będąc zewnętrznym plikiem interpretowanym w czasie wykonywania, „testy kompilatora” nie będą uruchamiane automatycznie, dlatego też należy je wyraźnie dodać i myślę, że można to słusznie uznać za „test jednostkowy” tego Fragment kodu SQL. Wydaje się uzasadnione włączenie go do (potencjalnego) zestawu testów przeprowadzanych przy każdej modyfikacji pliku.

— gbr

3

Nawiasem mówiąc, ogólnie zaleca się dostęp do plików zewnętrznych, gdy można je zastąpić próbą lub czymś podobnym. I według większości definicji testy jednostkowe mogą uzyskiwać dostęp do plików zewnętrznych lub cokolwiek, jest to zdecydowanie zalecane, ponieważ może to znacznie spowolnić. Sklep może przepisać, że nie można dodawać testów, które uzyskują dostęp do plików do zestawu testów, które są najczęściej uruchamiane, ale nie powoduje to, że takie testy nie są godne oznaczenia „test jednostkowy”, po prostu sprawiają, że „nie są” do umieszczenia w najczęściej uruchamianym pakiecie testów tego projektu ".

— gbr

2

@Warbo Dostęp do plików (ogólnie) jest złą praktyką, a (najważniejszym) powodem jest to, że nie są one powolne, jeśli zawierają „GB odczytane przez niestabilne łącze NFS”, są powolne, jeśli np. Cytują Michaela Feathersa , zajmują 1/10 sekundy. To dlatego, że chcesz uruchamiać testy tak często, jak to możliwe, najlepiej przy każdej zmianie w IDE, a gdy masz ich dużo (tak jak powinieneś), nawet 10-sekundowe kumulują się do godzin. (ciąg dalszy ...)

— gbr

1

@Warbo .. To powiedziawszy, liczy się całkowity czas, jaki zajmują, więc jeśli masz bardzo mały projekt, który na pewno pozostanie mały, możesz być znacznie bardziej wyrozumiały co do szybkości poszczególnych testów. A jeśli naprawdę nie chcesz często ich uruchamiać, możesz nawet poprosić o telefon do pracownika OPMROC w celu pobrania i przefaksowania pliku z szafki. Możesz też być bardziej rozluźniony, gdy masz jeszcze kilka testów, i wrócić, aby przyspieszyć je, gdy zaczynają brać zbyt dużo, ale musisz wziąć pod uwagę, że to dług, który gromadzisz.

— gbr

14

Michael Feathers mówi to w swojej książce Skutecznie działając ze starszym kodem:

W branży ludzie często zastanawiają się, czy poszczególne testy są testami jednostkowymi. [...] Wracam do dwóch cech: czy test przebiega szybko? Czy pomoże nam to szybko zlokalizować błędy?

Czy Twój test pomoże szybko zlokalizować błędy i działać szybko? Jeśli tak, zrób to! Jeśli nie, to nie rób tego! To takie proste!

To powiedziawszy, pracujesz w otoczeniu z innymi ludźmi i musisz się z nimi dogadać. Być może będziesz musiał zrobić to po swojemu, nawet jeśli prywatnie się z tym nie zgadzasz.

— CJ Dennis
źródło

To dobra zasada, ale oszczędziłby sobie zamieszania, gdyby napisał „ czy dodać określone testy do najczęściej uruchamianego zestawu testów ”, zamiast mieszać się z terminem „test jednostkowy”.

— gbr

1

@gbr Jeśli wyniki testu są dokładne, jedyną ważną rzeczą jest szybkość jego działania. Jeśli mam 100 testów, z których każdy uruchamia się w czasie poniżej 0,1 s, w sumie będą one działać w mniej niż 10 sekund. Cieszę się, że często je uruchamiam. Jeśli mam 1000 testów, zajmą one do 1m40. To za długo, nie będę ich często uruchamiał, ale będę je uruchamiał, gdy wprowadzę zmiany w mniejszej grupie 100 testów. Nie obchodzi mnie, czy technicznie jest to test akceptacyjny czy coś innego. Jeśli pomoże mi szybciej znaleźć błędy, zrobię to bez względu na semantykę. Test zapewnia wartość tylko wtedy, gdy jest uruchamiany.

— CJ Dennis,

W większości się zgadzam (niezależność to kolejna bardzo ważna rzecz, np.), Ale mimo wszystko byłoby lepiej, gdyby Michael Feathers nie pogłębił zamieszania na temat tego, co oznacza „test jednostkowy”. Nie to, że jest szczególnie winien za to zamieszanie (a jego książka jest doskonała w części, którą do tej pory przeglądałem). W każdym razie robiłem raczej drobną kwestię.

— gbr

@gbr Nie redefiniuje testów jednostkowych, mówi, że to nie powinno być twoje kryterium włączenia. Twoim kryterium powinna być użyteczność i właśnie to definiuje.

— CJ Dennis

Przeczytałem ponownie tę sekcję; Nie jestem pewien, nie jest dla mnie jasne, czy ma to być (rodzaj) definicja, czy tylko kryterium. Ale tak naprawdę „ Czy może nam to pomóc w szybkim lokalizowaniu błędów ” może równie dobrze sugerować to, co powiedział wcześniej, o izolacji itp. Mogłem więc zawracać sobie głowę niczym (chociaż sama odpowiedź wciąż może być źle interpretowana)

— gbr

10

Czasami pisałem podobne testy dla plików kodu źródłowego, plików konfiguracyjnych i tak dalej. Nie nazwałbym ich testami jednostkowymi, ponieważ (a) uzyskują dostęp do systemu plików i mogą nie być ultraszybkie (b) nie dbam o to, czy są wykonywane przy każdym zameldowaniu (w przeciwieństwie do nocnego na Serwer CI).

Możesz nazwać je testami integracji; z pewnością są bliżej tej perspektywy niż testy jednostkowe.

Mój własny termin dla nich to testy zasobów . IMHO są całkowicie uzasadnione, jeśli są wykonywane co noc na serwerze CI: są minimalne koszty, a przy rozsądnym użyciu wyraźnie zwiększają wartość. Jedna definicja rozsądnego : jeśli test sprawdza problem, który spowodował problem (taki jak wspomniane kodowanie).

— Michael Easter
źródło

4

Test jednostkowy polega na testowaniu metody lub „jednostki” kodu. Testujesz najmniejszą grupę logiki i kodu w swoim oprogramowaniu.

Później, kiedy dołączysz do tego z innymi jednostkami, przeprowadzisz testy integracji.

Mam nadzieję, że szef zespołu zachęcił do inicjatywy i powinien był zaproponować alternatywne propozycje. Zdecydowanie masz dobry pomysł.

Twój SQL jest kodem, podobnie jak każdy język niższej generacji, taki jak C # lub Java, i jako taki powinien zostać przetestowany. A weryfikacja i walidacja należą do wszystkich poziomów testowania. Tak więc kodowanie i instrukcje SET są uwzględnione, ale niekoniecznie wyłącznie testowane. Ogólne rzeczy, takie jak zakończenia linii lub zamykanie, zwykle można po prostu użyć haka SCM lub funkcji.

Najlepszą praktyką jest przeprowadzenie testów regresji, aby upewnić się, że wcześniejsze błędy nie zostaną ponownie wprowadzone. Zasadniczo testy są tworzone przy dowolnej rozdzielczości błędu. Jeśli te błędy nie są objęte testami regresji na poziomie jednostki / integracji lub systemu, a następnie ponownie wprowadzone, jest to problem zespołowy, procesowy, a nie indywidualny.

Chodzi o to, że ... błędy składniowe, brakujące instrukcje lub bloki logiczne wewnątrz „jednostki” zwykle nie są testowane. Testujesz wejścia i wyjścia urządzenia w różnych kombinacjach, testując wiele możliwości, które można wygenerować.

Wracając do brakujących instrukcji SET - pomagają poinformować o wielu możliwościach wejścia i wyjścia do testowania. Jaki test napisalibyście, że NIE POWINIENEŚ, gdybyście pominęli dowolny wybrany ZESTAW?

— Ross
źródło

Testowanie „jednostki kodu” to jedno podejście do testowania jednostki. Z mojego doświadczenia wynika, że prowadzi to do kruchych testów i masywnego wzdęcia (np. Nadmiernego kpiny). Alternatywnym i lepszym IMHO podejściem do testowania jednostkowego jest „jednostka funkcjonalności”. Nie ma znaczenia, czy jakaś funkcjonalność (powiedzmy „ustawienie ciasteczka po zalogowaniu”) wymaga jednej metody lub kilkunastu wzajemnie komunikujących się procesów, wciąż jest to jedna jednostka.

— Warbo,

@Warbo - nazwałbym to bliższym (ale nie) testowaniem integracji. Testy jednostkowe nie wymagają niczego nadmiernego ani masowego. Testy jednostkowe powinny być małe i szybkie. W rzeczywistości testowanie pod kątem funkcjonalności prowadzi do tego, co opisujesz. Kruche testy to te, które są 1. większe lub robią więcej, niż powinny. 2. silnie powiązane 3. nie ponosisz żadnej odpowiedzialności.

— Ross

3

Jeśli masz pliki, które stają się częścią Twojego produktu, ich zawartość musi być poprawna. Nie ma powodu, dla którego nie zweryfikowałbyś tego. Na przykład, jeśli potrzebujesz sześciu 1024 x 1024 obrazów w jakimś folderze, to napisz test jednostkowy, który sprawdzi, czy dokładnie to masz.

Ale prawdopodobnie nie masz tylko plików, masz także kod, który czyta pliki. Możesz napisać test jednostkowy dla tego kodu. W powyższym przykładzie funkcja odczytu jednego z sześciu obrazów zwraca do pamięci obraz 1024 x 1024 (lub cokolwiek, co miałby wytworzyć).

W każdym razie może to nie być test jednostkowy, ale jest to test przydatny. A jeśli używasz szkieletu testu jednostkowego, który pozwala ci przeprowadzić użyteczny test (który nie jest testem jednostkowym), dlaczego nie użyć szkieletu testu jednostkowego?

— gnasher729
źródło

2

Być może nie rozumiem twojego problemu, ale dla mnie to brzmi jak problem, który nie powinien być przechwytywany przez jakiś dedykowany test, ale po prostu przez system kontroli wersji . Każda zmiana w bazie kodu powinna zostać sprawdzona po poprawce przed zatwierdzeniem. Prostym sposobem na to w git jest dodanie zmian za pomocą

git add -p

Spowoduje to, że dla każdej zmiany w pliku tekstowym katalog roboczy zapyta, czy naprawdę chcesz go zachować. Umożliwiłoby to na przykład usunięcie tych „wstępnych SETstwierdzeń”.

Gdyby kodowanie całego pliku uległo zmianie, wydarzyło się coś innego: algorytm nie rozróżniałby starego i nowego pliku, a zatem git add -pnie dodałby niczego. Byłoby to wtedy widoczne w innym poleceniu, które wykonałbym przed jakimkolwiek zatwierdzeniem, mianowicie

git status

Którą tu widać plik podświetlony na czerwono, co oznacza, że są zmiany. Badanie, dlaczego nie udało się tego zrobić, git add -pszybko uwidoczniłoby problem.

— po lewej stronie
źródło

módlcie się, powiedzcie, w jaki sposób pomoże to przyszłemu twórcy uniknąć dokładnie tego samego problemu? ... rzecz w automatycznych testach (także w odniesieniu do twierdzeń i projektu na podstawie umowy) polega na tym, że są one zautomatyzowane .

— vaxquis

@vaxquis zapobiega dokładnie temu samemu problemowi - choć nieco przypadkowo, jako efekt uboczny przepływu pracy, który jest dobrym pomysłem z różnych powodów. Chodzi mi o to, że ten problem może się zdarzyć na wszystkich pokazach, że zespół OP nie bardzo dobrze wykorzystał VCS. - Nic przeciwko automatycznym testom, ale ich wartością jest testowanie właściwości semantycznych, które mogą ulec uszkodzeniu przez nieszkodliwe zmiany w logice programu. Nie chodzi o sprawdzenie każdego możliwego głupiego sposobu, w jaki kod źródłowy mógłby się zmienić.

— leftaroundabout

według twojej logiki nie potrzebujemy pasów bezpieczeństwa; musimy tylko jechać ostrożniej i powodować mniej wypadków ... Przegapiłeś główny punkt podniesiony przez OP - błąd człowieka . Żadna ilość VCS nie może cię przed tym ochronić . Ponadto FWIW: jeśli test można zautomatyzować, należy go zautomatyzować. Ludzie są zawsze najsłabszymi ogniwami w procesach inżynieryjnych. gitjest najlepszym tego przykładem - doskonałym narzędziem, ale ledwo nadającym się do użytku dla zwykłych śmiertelników .

— vaxquis

@vaxquis Nie, nie! Pasy bezpieczeństwa są analogiczne do tego rodzaju testów, które mają sens: wychwytują szeroki zakres sytuacji, które mogą wystąpić przypadkowo. Test kodowania plików byłby analogiczny do robota, który podąża za tobą i zapobiega uduszeniu się przez wkładanie fasoli do nosa.

— leftaroundabout

Według PO, pliki znajdujące się w złym formacie nie stało dwa razy już, więc najwyraźniej są prawdopodobne przez przypadek.

— gnasher729,

1

Pod innym kątem do rozważenia: skoro te dwa warunki są wymagane do uruchomienia programu, nie powinieneś osadzić logiki blisko logiki wykonania? Mam na myśli: testujesz istnienie pliku przed jego odczytaniem i / lub weryfikujesz jego zawartość, prawda? więc jak to jest inaczej? Myślę, że ponieważ jest to zewnętrzny zasób kodu, powinien zostać sprawdzony w czasie wykonywania, zanim zostanie faktycznie użyty. Wynik: silniejsza aplikacja, nie trzeba pisać dodatkowych testów.

— Dr Gianluigi Zane Zanettini
źródło

1

W jaki sposób porażka tylko w czasie wykonywania powoduje, że jest to silniejsza aplikacja? Jasne, może być właściwe, aby kontrole środowiska wykonawczego były również blisko źródła problemu, ale jeśli można wykryć błędy, zanim spowodują problemy w środowisku uruchomieniowym, jest o wiele lepiej, nie sądzisz? Czy na pewno znasz automatyczne testowanie?

— gbr

1

„W jaki sposób porażka tylko w środowisku uruchomieniowym sprawia, że jest to silniejsza aplikacja?” Zgłaszaj wyjątek, jeśli sprawdzenie się nie powiedzie. W teście po prostu sprawdź, czy sekcja testowanego kodu zwraca oczekiwany wynik: to usuwa obciążenie, aby sprawdzić jeszcze jeden powód niepowodzenia.

— Dr Gianluigi Zane Zanettini

1

Twoja strategia nie ma (prawie) nic wspólnego z testami jednostkowymi i testami automatycznymi, jest inna, ma różne zastosowania.

— gbr

1

Chciałem to zasugerować. Błąd jest szczegółem implementacji; Wyobrażam sobie, że odpowiedzi byłyby bardzo różne, gdyby podejrzane kodowanie było w polu prywatnym, a nie w osobnym pliku! Wygląda na to, że OP ma 2 problemy: pliki zasobów mogą być źle zakodowane, a produkcja zachowuje się inaczej niż programista. Sprawdzając plik w czasie wykonywania, tuż przed jego użyciem, rozwiązujemy drugi problem: dev i prod zgłoszą ten sam błąd. Testy jednostkowe mogą następnie skupiać się na faktycznej funkcjonalności, a nie na szczegółach implementacji; te „wewnętrzne” kontrole będą przeprowadzane podobnie jak metody prywatne.

— Warbo,

1

@ Dr.GianluigiZaneZanettini Bah ... poddaję się ... Jak widzę, twoja odpowiedź, w najlepszym razie, po „wyjaśnieniach” w komentarzach była nie na temat (nie odpowiedź na pytanie), ale w rzeczywistości w tej chwili jest po prostu źle! nie musisz pisać dodatkowych testów ??? Nie mam wystarczającej reputacji, aby ją głosować, ale uważam, że to zrobiłem. I nie sądzę, aby kontynuowanie tej rozmowy miało dużą wartość.

— gbr

1

Testy mają taki sam kod jak każdy inny i, jeśli są wystarczająco złożone, również korzystają z ... testów jednostkowych. Najprostszym wydaje się dodanie takich kontroli warunków wstępnych bezpośrednio do testu.

Większość testów jest wystarczająco prosta, aby tego nie wymagać, ale jeśli niektóre są wystarczająco złożone, nie widzę nic zasadniczo złego w tych kontrolach warunków wstępnych. Oczywiście test powinien również zakończyć się niepowodzeniem bez nich, ale dobry test jednostkowy informuje również, która jednostka zawodzi.

Skrypt używany jako część testu, który musi mieć określoną treść i kodowanie, jest prawdopodobnie jednostką. Może mieć znacznie więcej kodu i logiki niż reszta testu. Test z takim skryptem nie jest najlepszym projektem w historii i, jeśli to możliwe, powinien zostać przekształcony w coś bardziej bezpośredniego (chyba że jest to test integracyjny).

— h22
źródło

1

autor nie mówi nigdzie, że ten skrypt SQL jest częścią jakiegoś testu, wydaje się, że źle odczytałeś pytanie

— gbr

Trudno to zrozumieć, zakładam, że skrypt SQL jest częścią testu.

— h22

twój komentarz „Trudno to zrozumieć” ...

— gbr

Trudne do zrozumienia. Głosowanie w dół na pytanie.

— h22

1

Po pierwsze - jednym z celów testów jest zapobieganie powtarzaniu się problemów w kodzie - dlatego absolutnie powinieneś pisać testy tego rodzaju.

Po drugie - nazywanie jest trudne. Tak, wyraźnie nie są to „testy jednostkowe”, ale mogą być pożądanymi i niezbędnymi częściami procesu kompilacji, ponieważ chronią cię przed oczywistymi błędami i ponieważ szybciej informują cię o błędach (zwłaszcza, że nie widzisz konsekwencje dla dev box).

Tak więc pytanie naprawdę brzmi (powinno być w twoim kontekście) bardziej o tym, kiedy i jak te testy są uruchamiane, niż czym one są.

W przeszłości korzystałem z tego rodzaju testów - zaoszczędzili nam sporo bólu.

— Murph
źródło

I jeśli ktoś chciałby wyjaśnić opinię, doceniłbym to

— Murph

1

Testy jednostkowe polegają na wykonywaniu pojedynczej jednostki kodu w celu potwierdzenia, że generuje poprawny wynik dla prawidłowego wejścia. Izolacja powinna sprawić, że zarówno testowana jednostka, jak i sam test będą powtarzalne, tj. Nie powinny zależeć od efektów ubocznych ani ich wprowadzać.

SQL nie jest dokładnie czymś, co można przetestować w oderwaniu, więc każdy test SQL nie jest dokładnie testem jednostkowym i, z wyjątkiem instrukcji SELECT, prawie na pewno wywoła efekt uboczny. Możemy to nazwać testem integracyjnym, a nie testem jednostkowym.

Zawsze rozsądnie jest zapewnić, aby każda wada, która może zostać wprowadzona, mogła zostać wykryta jak najwcześniej w cyklu rozwojowym, a korzystne jest, aby zrobić to w sposób ułatwiający zidentyfikowanie źródła wady, aby można było szybko poprawione.

Testy, o których mowa, mogą być bardziej odpowiednio przeniesione poza ciało „testów jednostkowych” i umieszczone gdzie indziej, ale nie należy ich całkowicie usuwać, jeśli robią coś pożytecznego, jak ochrona przed możliwym wprowadzeniem usterki, której śledzenie może zająć wiele godzin. na dół.

— Zenilogix
źródło