JUnit + DbUnit: Przełącz połączenie z bazą danych między środowiskami programistycznymi a testowymi

Question

Przygotowuję pewne testowe rusztowanie wokół istniejącego projektu. Obejmuje to niektóre testy integracyjne, używając JUnit i DbUnit. Przygotowałem także instalację Jenkinsa do ciągłej integracji.

Mój problem polega na zmianie połączeń DB między środowiskiem programowania i testowania. Posiadam własny lokalny produkt do szybkiego testowania i badania ad-hoc. W miarę rozwoju prac przeprowadzam testy przeciwko mojej prywatnej bazie danych, ponieważ jest to szybsze i nie zepsuje niczyjego dnia z błędnym kodeksem pracy w toku.

Po wpisaniu kodu Jenkins uruchomi moje testy. W tej chwili wciąż wskazuje na moją lokalną bazę danych. Wolałbym, żeby Jenkins przeprowadzał testy na innej bazie danych, która znajduje się w środowisku testowym.

Czy istnieje najlepsza praktyka/strategia/technologia/itp. Do zmiany połączeń z bazami danych do testowania bez konieczności zmiany kodu? Punkty premiowe, jeśli rozwiązanie pozwala Jenkinsowi na przeprowadzenie tych samych testów przeciwko wielu DB (powinno być możliwe, ponieważ DbUnit jest agnostyczny).

---

Modyfikacje dokładniejsze informacje

produkt jest duży, z kilkudziesięciu różnych oddziałującymi składnikami, (zwykle w oddzielnych VMS/procesów). W żywym systemie różne procesy zwykle przekazują przez bazę danych. IE, proces interfejsu użytkownika zapisuje zmiany w tabeli, a proces back-end sprawdza tę tabelę pod kątem zmian. Tak, to okropne. Do testowania integracji, konfiguruję system za pomocą interfejsu użytkownika i przechwytuję ten stan za pomocą DbUnit. Mogę wtedy uruchomić testy przeciwko temu "wejściu".

Mój komponent i wszystkie nowe komponenty są zarządzane przez maven. Połączenia DB są obecnie zakodowane na stałe w konfiguracji testowej. Działa system DbUnit; Chciałbym móc zmienić bazę danych, do której odnoszą się moje testy, w zależności od tego, czy są one uruchamiane przeze mnie w moim środowisku programistycznym, czy uruchamiane przez Jenkinsa w środowisku testowym.

Answer 1

Zakładając, że możesz zdalnie przekazać parametry połączenia z bazą danych dla swoich testów do pliku .properties lub .xml, i że używasz Mavena, to jednym z podejść jest użycie właściwości Maven (i opcjonalnie profili) w celu zdefiniowania każdego środowiska i użycia filtrowanie zasobów w celu skonfigurowania tych właściwości w pliku konfiguracyjnym.

Na przykład, załóżmy, że podczas badania, że ​​uda Ci się uzewnętrznić swoje parametry łączność z bazami danych w pliku o nazwie datasource.properties w src/test/resources, który wygląda tak:

datasource.driverClassName = ${test.datasource.driverClassName} 
datasource.url = ${test.datasource.url} 
datasource.username = ${test.datasource.username} 
datasource.password = ${test.datasource.password} 

I masz to w POM:

<build> 
    <testResources> 
    <testResource> 
     <directory>src/test/resources</directory> 
     <filtering>true</filtering> 
    </testResource> 
    </testResources> 
</build> 

Następnie możesz zdefiniować właściwości różnych obiektów, na przykład Maven, aby korzystać z różnych baz danych:

• Możesz zdefiniować wartości domyślne w sekcji POM w polu <properties>;
• Można zdefiniować specyficzne dla użytkownika bazy danych w sekcji <properties> dla każdego dewelopera (i Jenkinsa) settings.xml;
• Można zdefiniować niektóre profile w POM dla różnych środowisk (np. development, jenkins, anotherDB) i uruchomić kompilację z różnymi profilami.

Jeśli wybierzesz ostatnią opcję, możesz zmusić Jenkinsa do działania przeciwko wielu bazom danych, wykonując wiele kompilacji Mavena z jednego projektu Jenkinsa, różniących się tylko profilem. Powiedział, że byłoby lepiej mieć inny projekt Jenkins dla każdego środowiska.

Answer 2

Potrzebujesz więcej informacji o swoim narzędziu do kompilacji. Czy używasz Mavena? Gdzie przechowywane są informacje o połączeniu z bazą danych? Czy używasz wiosny?

Zrobiłem to obecnie, używam Mavena z właściwościami dla mojego głównego połączenia z bazą danych i oddzielnego zestawu właściwości dla mojego połączenia z testową bazą danych.

Ponieważ używam Springa, wewnątrz zasobów testowych mave plik appContext, który przechowuje mój komponent bean źródła danych i odwołuje się do właściwości testu.

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy- method="close"> 
    <property name="driverClassName" value="${test.jdbc.driverClassName}"/> 
    <property name="url" value="${test.jdbc.url}"/> 
    <property name="username" value="${test.jdbc.username}"/> 
    <property name="password" value="${test.jdbc.password}"/> 
    <property name="maxActive" value="100"/> 
    <property name="maxWait" value="1000"/> 
    <property name="poolPreparedStatements" value="true"/> 
    <property name="defaultAutoCommit" value="true"/> 
</bean> 

Answer 3

Wiele zależy od środowiska wdrożenia. Jeśli wdrażasz do kontenera (tomcat, jboss itp.), Użycie połączenia JNDI oddzieli Cię od środowiska DB. Jeśli budujesz samodzielny program java, musisz samodzielnie określić środowisko i wybrać profil połączenia db.

Jednym ze sposobów na uzyskanie oddzielnej konfiguracji bazy danych dla każdego środowiska i uwzględnienie jej w swoim wdrożeniu. W ten sposób nie musisz komplikować kodu, martwiąc się, jakie jest twoje środowisko.

Innym sposobem jest przekazanie środowiska do twojego programu i pozwolenie Twojemu kodowi na określenie, której konfiguracji użyć.