Czy są jakieś ramy testowania jednostek agnostycznych w języku? [Zamknięte]

11

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

Podaj protokół poleceń w postaci czystego tekstu, a następnie użyj go expectdo wdrożenia testów.

— SK-logic,

@ SK-logic, o których nie słyszałem 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.

— Bringer128

dlaczego dziedzictwo Możesz także mieć nowoczesny system w stylu uniksowym. W każdym razie nigdy nie istnieje uzasadnione uzasadnienie braku udostępnienia interfejsu skryptowego dla jakiejkolwiek funkcji.

— SK-logic,

@ SK-logic Przepraszamy za brak jasności. Powiedziałem „starsze”, ponieważ przenoszenie jest zwykle wykonywane od legacy language xdo fancy new language y. Nie próbowałem sugerować niczego o Uniksie!

— Bringer128,

@ Bringer123, nawiasem mówiąc, moją małą sztuczką do przeprowadzenia tego rodzaju integracji uniksowej bez jakiejkolwiek przyzwoitej obsługi Uniksa (np. Bez odpowiednich potoków) jest osadzenie języka skryptowego i zapewnienie dostępu do jego REPL przez port TCP (z REPL działa w osobnym wątku). Jest to zarówno potężne narzędzie do debugowania, jak i silnik automatyzacji testów. To podejście działa dosłownie ze wszystkim (osadzony język skryptowy może być naprawdę niewielki, może nawet być naprzód w scenariuszu ograniczonych zasobów).

— SK-logic

6

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ą.

— David
źródło

+1 za automatyczne testy wysokiego poziomu. Zdecydowanie warto byłoby je wyprodukować.

— Bringer128,

1

„Nie sądzę, że można pisać testy jednostkowe w innym języku”. : licznik przykład: w .NET można pisać testy jednostkowe C # w Visual Basic (lub innym języku obsługującym .NET). Kilka lat temu była nawet promowana przez Microsoft jako najlepsza praktyka, ponieważ zmniejsza ryzyko popełnienia zarówno w kodzie, jak i testowania tego samego błędu związanego z językiem (a konkretnie względnego niezrozumienia go przez programistę). Uzgodniono, że w Fortranie nie można pisać testów jednostkowych w celu przetestowania kodu PHP.

— Arseni Mourzenko

2

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.

— Péter Török
źródło

1

Myślę, że to pokazuje problem z moim pytaniem. Jeśli mogą łatwo współpracować, po co portować? A jeśli nie mogą, bariera językowa uniemożliwia wykonywanie testów jednostkowych w różnych językach.

— Bringer128,

@ Bringer128, zwolennicy nowej rasy języków JVM twierdzą, że określone problemy można rozwiązać szybciej, przy znacznie mniejszym i czystszym kodzie niż w Javie. Moje ograniczone doświadczenie ze Scalą to potwierdza.

— Péter Török

Groovy równie dobrze współpracuje z Javą.

— user281377,

1

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 ++.

— BЈовић
źródło

1

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.

— Javier
źródło

0

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

— rrsguru
źródło

2

wydaje się, że nie oferuje to nic istotnego w porównaniu z punktami przedstawionymi i wyjaśnionymi w poprzednich 4 odpowiedziach

— gnat