Rozwiązywanie Java classpath cholery w dziedzictwo junit testowego pakietu

Question

Załóżmy, że mam zestaw testowy spuścizna JUnit, który obejmuje następujące testy:

public class AwesomeTest { 
    public void testBusinessLogic() { 
    ... 
    [awesome mocking library] 
    ... 
    } 
} 

public class AmazingTest { 
    public void testBusinessProcess() { 
    ... 
    [amazing xml operation] 
    ... 
    } 
} 

Załóżmy teraz, że niesamowite biblioteka Mocking opiera się na awesome biblioteki generacji BCEL kodu bajtowego, który zawiera klasę org.useful.XMLClass i ta biblioteka ma wersję 1 XMLClass.

Załóżmy teraz, że operacja Amazing Xml opiera się na Amazing Xml Library, która zawiera klasę org.useful.XMLClass, a ta biblioteka ma wersję 2 klasy XML.

Załóżmy również, że wersja 2 tej klasy nie jest wstecznie zgodna z wersją 1 - tak więc jakakolwiek wersja ma wyższy priorytet w ścieżce klasy - powoduje ona rozłączenie zależności drugiej wersji.

Załóż również, że istnieje 400 testów opartych na niesamowitej bibliotece szyderczej - więc przepisanie nie jest pożądaną opcją.

Załóż również, że niektóre ważne funkcje biznesowe zostały zbudowane z niesamowitymi bibliotekami xml - i zdecydowanie nie należy ich przepisywać.

Jak rozwiązać tę sytuację z piekłem klaskowym - poza uruchomieniem testów mrówek (zakładając, że używasz Mrówki) dwa razy z dwiema ręcznie zamawianymi ścieżkami klas i ręcznie określonymi podzestawami testowymi? (Jestem otwarty na pomysł z niestandardowymi klasami ładującymi - ale wydaje się, że jest to ten sam poziom obsługi, co podwójna niestandardowa ścieżka klasy z rozwiązaniem ant).

Answer 1

Wierzę, że całkiem przejrzyste rozwiązanie jest możliwe przy użyciu agenta Java i klasy niestandardowej ładowarka. Pomysł jest następujący:

1. Użyj Instrumentation Framework (agent Java), aby przechwycić klasy po załadowaniu. Po wykryciu klasy znajdującej się w Awesome Mocking Library zastąp wszystkie odwołania do org.useful.XMLClass na przykład intercepted.org.useful.XMLClass.
2. Utwórz niestandardowy program ładujący klasy, w którym sprawdzisz, czy żądana klasa to intercepted.org.useful.XMLClass. Jeśli tak, załaduj wersję XMLClass używaną przez bibliotekę szyderczą. Wszystkie pozostałe żądania mogą być obsługiwane domyślnie.

Użyj niestandardowego programu ładującego klasy i dołącz agenta Java podczas uruchamiania testów, a wszystko powinno działać poprawnie, tak jakby nie było konfliktu zależności.

Answer 2

myślę odpowiedź Stevena jest super - w trosce o kompletność i ze względu na to pytanie, ale tak wiele głosów - Chciałem podzielić wszystkie alternatywy Myśleliśmy (w tym tych złych)

1. działowe testów (lub niektóre z testów) na inną kolejność klasy klasu (wada - może spowodować, że nie zauważysz innych ważnych problemów z testami - nie jest realną opcją)
2. Cofnij Niesamowite działanie xml i zaimplementuj inny sposób (biorąc pod uwagę inwestycję w związku z tym i faktem, że inne operacje zostały wyczerpane - zostało to oddalone)
3. Przepisz testy za pomocą nowej biblioteki szyderczej (jest to dobre rozwiązanie na dłuższą metę - w krótkim okresie okaże się większe niż nasz obecny projekt, ponieważ istnieją setki i setki)
4. Utwórz niestandardową wersję niesamowita szydercza biblioteka, która używa nowszej wersji org.useful.XMLClass (okazało się, że jest większa niż nasz obecny projekt).
5. Wyodrębnij szkodliwą klasę ze źródła i umieść starszą wersję w testowej ścieżce klas nadpisując bibliotekę źródłową (zwróciła się że było to uwikłane w kilka innych klas - więc było to nietrywialne)
6. Wykorzystaj fantastyczny pomysł Stevena powyżej - znowu okazało się to nietrywialne
7. Ustaw testy za pomocą @Ignore - i umieść je w kolejce do przepisywania przyszłych projektów.