Czy naprawdę pytasz: „czy pomogłyby tutaj testy jednostkowe?”, Czy pytasz: „czy pomógłby w tym jakikolwiek test?”.
Najbardziej oczywistą formą testowania, która by pomogła, jest wstępne stwierdzenie w samym kodzie, że identyfikator gałęzi składa się tylko z cyfr (zakładając, że jest to założenie, na którym koder opierał się podczas pisania kodu).
Mogło to nie powieść się w jakimś teście integracji, a gdy tylko zostaną wprowadzone nowe identyfikatory gałęzi alfanumerycznej, asercja wysadzi w powietrze. Ale to nie jest test jednostkowy.
Alternatywnie może istnieć test integracji procedury, która generuje raport SEC. Ten test zapewnia, że każdy rzeczywisty identyfikator oddziału zgłasza swoje transakcje (i dlatego wymaga rzeczywistych danych wejściowych, listy wszystkich używanych identyfikatorów oddziału). Więc to też nie jest test jednostkowy.
Nie widzę żadnej definicji ani dokumentacji zaangażowanych interfejsów, ale może się zdarzyć, że testy jednostkowe prawdopodobnie nie wykryły błędu, ponieważ jednostka nie była wadliwa . Jeśli jednostka może założyć, że identyfikatory gałęzi składają się tylko z cyfr, a programiści nigdy nie zdecydowali, co powinien zrobić kod, gdyby tego nie zrobił, to nie powinninapisz test jednostkowy, aby wymusić określone zachowanie w przypadku niecyfrowych identyfikatorów, ponieważ test odrzuciłby hipotetyczną poprawną implementację jednostki, która poprawnie obsługiwała alfanumeryczne identyfikatory gałęzi, i zwykle nie chcesz pisać testu jednostkowego, który uniemożliwia prawidłowy przyszłe wdrożenia i rozszerzenia. A może jeden dokument napisany 40 lat temu domyślnie zdefiniowany (poprzez pewien zakres leksykograficzny w surowym EBCDIC, zamiast bardziej przyjaznej dla człowieka reguły zestawiania), że 10B jest identyfikatorem testu, ponieważ w rzeczywistości mieści się w przedziale od 089 do 100. Ale potem 15 lat temu ktoś postanowił użyć go jako prawdziwego identyfikatora, więc „usterka” nie leży w jednostce, która poprawnie implementuje oryginalną definicję: leży w procesie, który nie zauważył, że 10B jest zdefiniowany jako identyfikator testu i dlatego nie powinien być przypisany do gałęzi. To samo stanie się w ASCII, jeśli zdefiniujesz 089 - 100 jako zakres testowy, a następnie wprowadzisz identyfikator 10 $ lub 1.0. Po prostu zdarza się, że w EBCDIC cyfry pojawiają się po literach.
Jeden test jednostkowy (lub prawdopodobnie test funkcjonalny), który jest możliwymógł uratować dzień, jest testem jednostki, która generuje lub sprawdza nowe identyfikatory gałęzi. Test ten potwierdziłby, że identyfikatory muszą zawierać tylko cyfry i zostałby napisany, aby umożliwić użytkownikom identyfikatorów gałęzi przyjęcie tego samego. A może jest gdzieś jednostka, która importuje prawdziwe identyfikatory gałęzi, ale nigdy nie widzi tych testowych, i która mogłaby być testowana jednostkowo, aby upewnić się, że odrzuca wszystkie identyfikatory testowe (jeśli identyfikatory to tylko trzy znaki, możemy je wszystkie policzyć i porównać zachowanie walidator do filtru testowego, aby upewnić się, że pasują, co dotyczy zwykłego sprzeciwu wobec testów punktowych). Gdy ktoś zmienił reguły, test jednostkowy nie powiódłby się, ponieważ jest sprzeczny z nowo wymaganym zachowaniem.
Ponieważ test został przeprowadzony z dobrego powodu, punkt, w którym należy go usunąć ze względu na zmienione wymagania biznesowe, staje się okazją dla kogoś, kto dostanie to zadanie, „znajdź każde miejsce w kodzie, które zależy od zachowania, które chcemy zmiana". Oczywiście jest to trudne, a zatem niewiarygodne, więc w żadnym wypadku nie gwarantuje uratowania dnia. Ale jeśli uchwycisz swoje założenia w testach jednostek, których zakładasz właściwości, to dałeś sobie szansę, więc wysiłek nie zostanie całkowicie zmarnowany.
Zgadzam się oczywiście, że gdyby jednostka nie została zdefiniowana z „zabawnym” wejściem, nie byłoby nic do przetestowania. Fiddly podziały przestrzeni nazw mogą być trudne do prawidłowego przetestowania, ponieważ trudność nie polega na implementacji twojej śmiesznej definicji, polega na upewnieniu się, że wszyscy rozumieją i szanują twoją zabawną definicję. To nie jest lokalna właściwość jednej jednostki kodu. Ponadto zmiana niektórych typów danych z „ciągu cyfr” na „ciąg znaków alfanumerycznych” przypomina tworzenie Unicode w programie opartym na ASCII: nie będzie to łatwe, jeśli kod będzie silnie sprzężony z oryginalną definicją i kiedy typ danych ma fundamentalne znaczenie dla tego, co robi program, a następnie często jest silnie sprzężony.
myślenie, że to w dużej mierze zmarnowany wysiłek, jest trochę niepokojące
Jeśli testy jednostkowe czasami kończą się niepowodzeniem (na przykład podczas refaktoryzacji), a robiąc to, dostarczają przydatnych informacji (na przykład Twoja zmiana jest błędna), to wysiłek nie został zmarnowany. To, czego nie robią, to sprawdzenie, czy system działa. Więc jeśli piszesz testy jednostkowe zamiast testów funkcjonalnych i integracyjnych, być może wykorzystujesz swój czas nieoptymalnie.