[JAVA] Récapitulatif de l'ordre d'exécution tel que la configuration de spock

Quand je regarde autour de moi, il y a des gens qui en sont dépendants, alors j'ai pensé que ce serait bien si je ne trébuchais pas.

tout à coup

spock Je ne vais pas l'expliquer en détail, mais il existe des nettoyages de configuration et un endroit pour définir les données de test appelé where.

Conclure rapidement Avec une table et une photo

Définition Horaire Remarques
setupSpec tester[classe]Au début de[une fois que]Bouge toi équivalent à statique
setup tester[Les données] [Chaque]Se déplace en premier
cleanup tester[Les données] [Chaque]Dernier passage à
cleanupSpec tester[classe]Au bout du[une fois que]Bouge toi équivalent à statique
where tester[Méthode]Au début de[Pour les données]Bouge toi équivalent à statique

Les lettres vertes sont statiques et les lettres rouges sont les autres, lisez à partir de la gauche

スクリーンショット 2020-04-01 20.32.17.png

Donc quel est le problème

Deux gros

static Comme il est équivalent à statique, le traitement d'initialisation utilisant, par exemple, les variables @ Autowired ne peut pas être appelé avec setupSpec / cleanupSpec.

Ne peut pas être utilisé à partir de where

Soyez prudent car cela a tendance à être fait

Ordre d'exécution

Il y en a beaucoup ici

Surtout dans le cas de la création de données de test impliquant maintenant, etc., il existe des cas où le test ne peut pas être créé comme prévu et le test peut être terminé.

Par exemple, si vous écrivez un code qui falsifie l'horloge système dans setup, créez des données de test y compris maintenant dans where, et effectuez un test de modèle. L'ordre est de falsifier l'horloge du système après avoir créé les données de test, afin qu'elle ne réponde pas aux attentes.

Dans ce cas, déplacez la configuration vers setupSpec

Si la configuration ne peut pas être effectuée dans le traitement statique, par exemple, inclure les données du côté where avec {} ʻet ajouter () ʻon le côté expect retardera l'exécution, mais Si vous voulez faire quelque chose de technique avec le code de test ** La plupart du temps, le code produit (= design) ** est faux, alors refactorisons-le docilement

C'est fini vite

Bonus: Image de code de l'exemple donné dans l'ordre d'exécution

Dans ce cas, cela fonctionne dans l'ordre de mkData () -> setClock ()

def setup() {
    setClock()
}

def test() {
    expect:
    sut.f(data) == exp

    where:
    data     || exp
    mkData() || ...
}

Fais ça

def setupSpec() {
    setClock()
}

def test() {
    expect:
    sut.f(data) == exp

    where:
    data     || exp
    mkData() || ...
}

Cela fonctionnera dans l'ordre setClock () -> mkData ()

def setup() {
    setClock()
}

def test() {
    expect:
    sut.f(data()) == exp

    where:
    data         || exp
    { mkData() } || ...
}

Cependant, pour l'instant, par exemple, il est beaucoup plus facile de tester en le passant comme argument que de le générer en interne dans sut.f, il est donc préférable de revenir en arrière pour revoir la construction existante.

def test() {
    expect:
    sut.f(data, date(2020, 3, 1)) == exp

    where:
    data     || exp
    mkData() || ...
}

Recommended Posts

Récapitulatif de l'ordre d'exécution tel que la configuration de spock
Seul résumé lié à la configuration du tutoriel Rails