Jak nadać właściwość systemową mojemu testowi za pomocą Gradle i -D

103

Mam program Java, który odczytuje właściwość systemu

System.getProperty("cassandra.ip");

i mam plik kompilacji Gradle, od którego zaczynam

gradle test -Pcassandra.ip=192.168.33.13

lub

gradle test -Dcassandra.ip=192.168.33.13

jednak System.getProperty zawsze zwróci wartość null .

Jedynym sposobem, jaki znalazłem, było dodanie tego w moim pliku kompilacji Gradle za pośrednictwem

test {
    systemProperty "cassandra.ip", "192.168.33.13"
}

Jak to zrobić za pomocą -D

java testing gradle

— robkuz
źródło

1

Co się dzieje, gdy używasz gradle -Dcassandra.ip=192.168.33.13? W każdym razie zadanie testowe obejmuje jedną lub kilka nowych maszyn JVM. Musisz więc jawnie przekazać właściwości. Nikt jednak nie zmusza cię do zakodowania ich wartości w kompilacji.

— JB Nizet

Spójrz także na tę odpowiedź: stackoverflow.com/questions/23689054/ ...

— IgalS,

125

Opcja -P dotyczy właściwości gradle, a opcja -D dotyczy właściwości maszyny JVM. Ponieważ test może być rozwidlony w nowej maszynie JVM, argument -D przekazany do gradle nie zostanie przekazany do testu - wygląda na to, że widzisz takie zachowanie.

Możesz użyć właściwości systemowej w swoim testbloku, tak jak to zrobiłeś, ale oprzeć ją na właściwości przychodzącej gradle, przekazując ją z nią -P:

test {
    systemProperty "cassandra.ip", project.getProperty("cassandra.ip")
}

lub alternatywnie, jeśli przekazujesz go przez -D

test {
    systemProperty "cassandra.ip", System.getProperty("cassandra.ip")
}

— Jeff Storey
źródło

1

To nie działa dla mnie (testowane System.getProperties().stringPropertyNames().forEach(System.out::println);w kodzie Java, nie pojawia się)

— CLOVIS

Ostrzeżenie: getPropertywyrzuca, MissingPropertyExceptionjeśli właściwość nie zostanie znaleziona. Zamiast tego użyj odpowiedzi Eron: stackoverflow.com/a/43112126/915441

— Yngvar Kristiansen

1

Dodanie wartości domyślnych do gradle.propertieszapobiegnie wystąpieniu MissingPropertyException.

— Duncan Calvert

Żadna z tych metod nie działa. Cokolwiek robię, mojaWłaściwość jest zawsze zerowa. Dotyczy to również wszystkich metod wymienionych poniżej. Zastanawiam się, czy ma to coś wspólnego z nowszą wersją, bo wszystkie komentarze pochodzą z 2018 roku? @CLOVIS Czy znalazłeś rozwiązanie tego problemu?

— Hester Lyons

@HesterLyons Chciałem tylko wiedzieć, czy kompilacja jest testowana, czy normalnie działa, więc użyłem właściwości, które dodaje gradle podczas testowania; możesz zobaczyć kod tutaj: github.com/CLOVIS-AI/wildfyre-java/blob/master/src/main/java/…

— CLOVIS

27

Przeszedłem przez ten bardzo duży problem, z wyjątkiem tego, że nie chcę ponownie wyświetlać wszystkich właściwości podanych w wierszu poleceń w skrypcie gradle. Dlatego wysyłam wszystkie właściwości systemu do mojego testu

task integrationTest(type: Test) {
    useTestNG()
    options {
        systemProperties(System.getProperties())
    }
}

— MrSpock
źródło

Zachowaj ostrożność, gdy to robisz. Może łatwo zepsuć aktualne sprawdzanie Gradle, gdy właściwości systemu zmieniają się podczas wywołań.

— tym roku

9

Miałem przypadek, w którym musiałem przekazać wiele właściwości systemu do testowej maszyny JVM, ale nie wszystkie (nie chciałem przekazywać nieistotnych). W oparciu o powyższe odpowiedzi i używając subMapdo filtrowania tych, których potrzebowałem, zadziałało to dla mnie:

task integrationTest(type: Test) {
    // ... Do stuff here ...
    systemProperties System.getProperties().subMap(['PROP1', 'PROP2'])
}

W tym przykładzie tylko PROP1i PROP2zostaną przekazane, jeśli istnieją w JVM gradle.

— avivr
źródło

5

Oto wariant, który przekazuje wiele właściwości projektu do testowej maszyny JVM jako właściwości systemu. Preferuję właściwości projektu od właściwości systemu, aby zwiększyć elastyczność.

task intTest(type: Test) {
    systemProperties project.properties.subMap(["foo", "bar"])
}

Które można przekazać w wierszu poleceń:

 $ gradle intTest -Pfoo=1 -Pbar=2

I odzyskane w twoim teście:

String foo = System.getProperty("foo");

— Eron Wright
źródło

Podczas uruchamiania System.getProperty("someprop")przy użyciu tej metody subMap otrzymałem {someprop=foo}zamiast foo. Musiałem użyć systemProperty "foo", project.properties.subMap(["foo"]).get("foo")w build.gradle

— Yngvar Kristiansen

@YngvarKristiansen, gdzie (jak) korzystałeś systemProperty "foo"? tj. proszę o wyświetlenie pełnej linii kodu, w którym to zostało użyte? Próbuję wszystkiego, co sugeruje to pytanie, a Gradle nadal nie przekazuje żadnych argumentów. Mam nadzieję, że to rozwiąże!

— Hester Lyons,

@HesterLyons Przepraszam, nie zachowałem swojego kodu, więc już nie wiem: \ Zgadzam się, że wygląda nie na miejscu.

— Yngvar Kristiansen

Dziękuję @YngvarKristiansen. Od tamtej pory odkryłem, że mój problem jest spowodowany przez wtyczkę junit gradle, która była zawarta w moim gradle.build. Bardzo dziwne.

— Hester Lyons

0

Więc dzisiaj również natknąłem się na ten problem, a to, co zadziałało, było następujące:

ext.env='prod'
test {
  systemProperty 'env', System.properties['env'] ?: "${env}"
  println "# test environment: " + systemProperties['env']
  ...
}

Wywołuję swoje zadanie testowe za pomocą -Penv = dev i otrzymuję wartość „dev” na wydruku lub „prod”, jeśli nie wysyłam żadnej wartości, co jest dla mnie oczekiwanym zachowaniem.

Wartość jest również dostępna po stronie Java, używając System.getProperty ("env") .

Mój wniosek w tej sprawie jest taki, że wartość wejściowa (parametr) jest faktycznie przechowywana w Systemie , dzięki czemu jest dostępna za pośrednictwem System.properties ['env'] lub System.getProperty ("env") , podczas gdy dane wyjściowe (właściwość systemowa) są przechowywane w systemProperties macierz, co czytelny przez systemProperties [ 'env'] .

— Olivier B.
źródło