Unité de test Groovy2.0 avec Spock : setup( )

Je suis d'écriture de l'unité de test à l'aide de Spock groovy-2.0 , et à l'aide de gradle à exécuter. Si j'écris à la suite de la passe de test.

import spock.lang.Specification

class MyTest extends Specification {  

  def "test if myMethod returns true"() {       
    expect:
      Result == true;   
    where: 
      Result =  new DSLValidator().myMethod()

  }  
}

myMethod() est une méthode simple en DSLValidator classe, qui retourne vrai.

Mais si j'écris un setup() et la fonction créer l'objet dans setup(), mon test échoue: Gradel dit: ÉCHEC: java.lang.NullPointerException: Impossible d'appeler la méthode myMethod() sur l'objet null

Voici à quoi il ressemble avec setup(),

import spock.lang.Specification

class MyTest extends Specification {  

  def obj

  def setup(){
   obj =  new DSLValidator()
  }

  def "test if myMethod returns true"() {       
    expect:
      Result == true;   
    where: 
      Result =  obj.myMethod()

  }  
}

Quelqu'un peut-il aider?

Voici la solution que j'ai eu le problème:

import spock.lang.Specification

class DSLValidatorTest extends Specification {

  def validator

  def setup() {
    validator = new DSLValidator()
  }


  def "test if DSL is valid"() { 

      expect:
        true == validator.isValid()
  }  
}

OriginalL'auteur Masa | 2012-01-31

  1. 23

    Dans Spock objets stockés dans des champs d'instance ne sont pas partagés entre fonctionnalité méthodes. Au lieu de cela, toutes les fonctionnalités de la méthode devient son propre objet.

    Si vous avez besoin de partager un objet entre fonctionnalité méthodes, déclarer un @Shared champ.

    class MyTest extends Specification {
    @Shared obj = new DSLValidator()

    def "test if myMethod returns true"() {       
        expect:
          Result == true  
        where: 
          Result =  obj.myMethod()
    }
}
    class MyTest extends Specification {
    @Shared obj

    def setupSpec() {
        obj = new DSLValidator()
    }

    def "test if myMethod returns true"() {       
        expect:
          Result == true  
        where: 
          Result =  obj.myMethod()
    }
}

    Il y a 2 luminaire méthodes de configuration de l'environnement:

    def setup() {}         //run before every feature method
def setupSpec() {}     //run before the first feature method

    Je ne comprends pas pourquoi le deuxième exemple avec setupSpec() œuvres et échoue avec setup() parce que dans la documentation dit le contraire:

    Remarque: Le setupSpec() et cleanupSpec() méthodes de référence
    champs d'instance.

    Bizarre... Le Spock docs pourrait vraiment le faire avec des précisions sur ce... je ne dirais pas que obj est partagé entre fonctionnalité de méthodes, mais est en cours de mise en place avant chaque luminaire d'être appelé...
    Qu'est-ce que vous ne comprenez pas? @Partagé champ est partagé entre la fonction de méthodes et devrait être mis en place avec un champ d'initialiseur ou la setupSpec méthode. setup n'est pas un bon choix car il est appelé après que le where bloc a été évaluée.
    Merci pour la clarification
    Merci à tous de m'aider ici. Je ne veux pas utiliser l'partagé champ car qui sera la cause de défaut d'autres test à l'avenir. Besoin d'avoir instance individuelle de DSLValidator pour chaque fonction de la méthode. Le problème, c'est ce que Peter Niederwieser mention "installation n'est pas un bon choix car il est appelé après que le bloc où a été évaluée." J'ai finalement compris que les "où" bloc n'est pas bon, si je veux utiliser le programme d'installation et ne veulent pas d'une instance partagée entre l'avenir de la méthode. Veuillez voir, j'ai édité ma question d'origine de ma solution. Merci encore à tous.

    OriginalL'auteur Arturo Herrero