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
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
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
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() || ...
}