Zawsze byłem sceptycznie nastawiony do przepisywania działającego kodu - przenoszenie kodu nie jest tu wyjątkiem. Jednak wraz z nadejściem TDD i automatycznymi testami znacznie bardziej rozsądne jest przepisywanie i refaktoryzacja kodu.
Czy ktoś wie, czy istnieje narzędzie TDD, którego można użyć do przeniesienia starego kodu? Najlepiej byłoby wykonać następujące czynności:
- Napisz testy jednostkowe agnostyczne dla starego kodu, który przejdzie (lub zawiedzie, jeśli znajdziesz błędy!).
- Przeprowadź testy jednostkowe na innej podstawie kodu, które się nie powiodły.
- Napisz kod w swoim nowym języku, który przejdzie testy bez patrzenia na stary kod.
Alternatywą byłoby podzielenie kroku 1 na „Napisz testy jednostkowe w języku 1” i „Testy jednostek portu do języka 2”, co znacznie zwiększa wymagany wysiłek i trudno uzasadnić, czy stara baza kodu przestanie być utrzymywana po port (to znaczy, że nie zyskujesz ciągłej integracji na tej podstawie kodu).
EDYCJA: Warto zwrócić uwagę na to pytanie na StackOverflow.
unit-testing
language-agnostic
porting
Bringer128
źródło
źródło
expectdo wdrożenia testów.expect. Jeśli masz system starszego typu w stylu uniksowym, który komunikuje się z potokami za pomocą stdin i stdout, to z pewnością można użyć tego narzędzia. W rzeczywistości testowanie w dowolnym języku skryptowym byłoby dość łatwe.legacy language xdofancy new language y. Nie próbowałem sugerować niczego o Uniksie!Odpowiedzi:
Nie sądzę, że można pisać testy jednostkowe w innym języku.
Możesz jednak napisać testy integracji / akceptacji / interfejsu użytkownika / whaterver_you_name_it, które byłyby na bardzo wysokim poziomie i nie byłyby powiązane z językiem, w którym napisane jest twoje oprogramowanie.
Jeśli twoja aplikacja jest usługą internetową, możesz ją przetestować w dowolnym języku, pod warunkiem, że obsługuje on Twój protokół. Jeśli twoja aplikacja działa w przeglądarce, możesz użyć selenu (to pierwszy raz, który przyszedł mi do głowy, ale są też inne. Itd. Mogą być przypadki, w których nie działałoby, jak sądzę (może sprzętowe), wszystko zależy od rodzaju aplikacji, nad którą pracujesz.
Oczywiście nie będziesz mieć takiego samego zasięgu, jak w przypadku testów na poziomie jednostki (chyba że spędzasz dużo czasu), ale przynajmniej będziesz miał uprząż testową.
źródło
Myślę, że najbliżej twojego pomysłu są ramy testów jednostkowych w ekosystemach opartych na maszynach wirtualnych, takich jak Java VM. Przynajmniej Scala (i uważam też, że Groovy - nie jestem pewien co do Clojure) jest prawie idealnie kompatybilny z Javą. Oznacza to, że kod Scala można testować za pomocą JUnit, a kod Java można testować za pomocą ScalaTest. W ten sposób możesz (stopniowo lub jednocześnie) przepisać kod Java w Scali i nadal używać tych samych starych testów jednostek Java, aby zweryfikować jego poprawność. (Lub na odwrót - chociaż nie wyobrażam sobie ważnego powodu do migracji ze Scali z powrotem do Javy).
Prawdopodobnie to samo dotyczy języków interfejsu .NET CLI, np. C #, F #, ASP.NET i in.
Jednak poza VM / CLR jest to trudniejsze. Teoretycznie można skompilować testy jednostkowe i / lub testowany kod na inny język, taki jak C (taki jaki był i jest powszechny w nowych językach, takich jak wczesny C ++ itp.), Ale nie słyszałem o nikim, kto wypróbowałby to specjalnie z testy jednostkowe.
źródło
Taki framework nie istnieje, ponieważ musi być napisany w języku używanego kodu.
Na przykład framework do testowania kodu c ++ musi być napisany w c lub c ++. Korzystanie ze środowiska napisanego w c ++ może, ale nie będzie testować kodu ac, jeśli używa funkcji c ++.
źródło
Metodologie są różne, ale w moim przypadku duża część moich testów TDD ma tendencję do „testu integracji”, w przeciwieństwie do „testu jednostkowego”. Oznacza to, że większość z nich testuje cały program w zapytaniach niemal z życia, sprawdzając odpowiednie odpowiedzi.
W kilku przypadkach, gdy pisałem programy sieciowe (głównie protokoły specyficzne dla aplikacji), nie miałem pod ręką pełnego środowiska testowego, które wydawało mi się łatwe do wykonania, więc większość testów przeprowadziłem „w sieci”, w krótko mówiąc, napisałem bardzo prostego klienta w innym języku ze wspólną i prostą strukturą testową, a większość testów sprawdziła odpowiedzi serwera.
Mimo to, nawet w tych przypadkach, wprowadziłem kilka ręcznie walcowanych testów w prawdziwej aplikacji, aby przetestować niektóre części niesieciowe.
źródło
Język agnostyczny szkielet testowy to ogólny szkielet testowy odpowiedni do testu akceptacyjnego (punkt widzenia), a przypadki testowe w tym frameworku są zarządzane przez kontrolę jakości, np. Robotframework
źródło