Większość programistów wie, jak bolesne jest przypadkowe, niepotrzebne uruchamianie testów w kontekście aplikacji. Może to nastąpić w kontekście zadań Jenkins CI, przypadkowych uruchomień kompilacji lub po prostu rozwoju.

Jak zminimalizować prawdopodobieństwo niezamierzonego uruchomienia powolnych testów?

Rozdzielanie rzeczy

Jeśli twoje testy działają wolno, możesz oddzielić długie, złożone i rzadko używane testy od tych, które są szybkie, aby przyspieszyć lokalne wdrożenie.

Zazwyczaj testy jednostkowe są szybkie i nawet jeśli uruchomisz je przez pomyłkę, nie poczujesz się niekomfortowo. Testy integracyjne, kontraktowe i akceptacyjne mogą zająć kilka minut, jeśli projekt jest duży. Dlatego warto rozdzielić testy integracyjne i jednostkowe.

Struktura projektu

Niemodułowa struktura projektu java w src Folder zazwyczaj wygląda następująco:

Wszystkie testy jednostkowe i integracyjne są w test źródło. Nasz build.gradle wygląda następująco:

plugins {
    id 'org.springframework.boot' version '2.1.3.RELEASE'
    id 'java'
}

apply plugin: 'groovy'
apply plugin: 'io.spring.dependency-management'

group = 'com.inspeerity'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '1.11'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'

    testRuntime("org.codehaus.groovy:groovy-all:2.5.2")

    testImplementation('org.springframework.boot:spring-boot-starter-test')
    testImplementation("org.spockframework:spock-spring:1.2-groovy-2.5")
}

Dodanie nowego testowego katalogu źródłowego

Po utworzeniu integration/groovy katalog w src, możesz zauważyć, że IDE nie rozpoznaje go jako katalogu źródeł testowych:

przed dodaniem źródeł

Musimy dodać kolejne źródło testowe i katalog zasobów do projektu Gradle.

Dodajmy następujące linie do pliku build.gradle plik:

sourceSets {
    integration {
        groovy.srcDir "$projectDir/src/integration/groovy"
        resources.srcDir "$projectDir/src/integration/resources"
        compileClasspath += main.output + test.output
        runtimeClasspath += main.output + test.output
    }
}

Po odświeżeniu projektu gradle zobaczysz, że integration/groovy jest traktowana jako źródło:

Musimy dodać zależności do naszych źródeł testów integracyjnych:

configurations {
    integrationImplementation.extendsFrom testImplementation
    integrationRuntime.extendsFrom testRuntime
}

Od teraz możesz przenieść wszystkie swoje testy integracyjne do odpowiedniego folderu, a wszystkie z nich będą miały wszystkie zależności, które są zdefiniowane dla test zadanie.

Nie zapomnij zmienić testImplementation do integrationImplementation dla każdej zależności, która jest używana tylko przez testy integracyjne.

Definiowanie zadania integracji

Ostatnią rzeczą, która pozostała, jest zdefiniowanie zadania testu integracyjnego, aby działało ze źródłami zdefiniowanymi w integration sekcja:

task integrationTest(type: Test) {
    testClassesDirs = sourceSets.integration.output.classesDirs
    classpath = sourceSets.integration.runtimeClasspath
}

check.dependsOn integrationTest

The dependsOn siły liniowe do uruchomienia integrationTest zadanie podczas działania check które jest wykonywane przy każdej kompilacji.

Wnioski

Dzięki tej wiedzy można oddzielnie wykonywać testy integracyjne i jednostkowe, używając odpowiedniej nazwy zadania.

Następnym krokiem jest przygotowanie oddzielnych zadań Jenkinsa, które zostaną wykonane:

  1. Wykonuj testy jednostkowe po każdym wypchnięciu, aby uniknąć blokowania pracowników Jenkins.
  2. Uruchom wszystkie testy przed scaleniem, aby upewnić się, że wszystko działa.

Chcesz porozmawiać z naszymi ekspertami o niestandardowych rozwiązaniach programowych dla Twojej firmy?

 
4.2/5 - (78 głosów)