Wie mock-statische member-Variablen

Habe ich eine Klasse ClassToTest, die eine Abhängigkeit von ClassToMock. 

public class ClassToMock {

  private static final String MEMBER_1 = FileReader.readMemeber1();

  protected void someMethod() {
    ...
  }
}

Den unit-test-Fall für ClassToTest. 

public class ClassToTestTest {
  private ClassToMock _mock;

  @Before
  public void setUp() throws Exception {
     _mock = mock(ClassToMock.class)
  }

}

Beim verspotten heißt in der Methode setUp (), FileReader.readMemeber1(); ausgeführt wird. Gibt es eine Möglichkeit dies zu vermeiden? Ich denke, eine Möglichkeit ist die Initialisierung der MEMBER_1 innerhalb einer Methode. Irgendwelche anderen alternativen?

Dank!

  • Ich denke, dass es tools gibt, die es ermöglichen, Sie zu verspotten, sich statische Variablen, aber Sie beinhalten eine Menge hacks. Da diese Klasse ist schwierig zu testen, zu hören, was die tests werden versuchen, Ihnen zu sagen, und machen Sie Ihre Klasse mehr lose gekoppelt FileReader.
  • Frage: Ist Ihre Sorge nur, dass FileReader.readMember ausgeführt wird (D. H., dass unit-tests sollten nicht auf die Datei system), oder sind Sie auch wollen, verschiedene tests, verschiedene Werte für MEMBER_1?
  • Ja. Ich will nicht mit FileReader.readMember ausgeführt werden. Es ist eine andere Abhängigkeit.
  • Ich füge einen weiteren Schritt in meiner Antwort, dies sollte Ihr problem lösen.
InformationsquelleAutor pkrish | 2012-12-05
  1. 11

    Ihre ClassToMock eng gekoppelt mit FileReader, das ist, warum Sie nicht in der Lage sind test/mock es. Anstelle der Verwendung von Werkzeug, hack-byte-code, so können Sie verspotten es. Ich würde vorschlagen, Sie einige einfache refactorings an der abhngigkeit.

    Schritt 1. Kapseln Von Globalen Referenzen

    Diese Technik wird auch eingeführt in Michael Feathers ' s wunderbares Buch : Working effectively with Legacy Code.

    Den Titel ziemlich viel selbst erklärt. Statt direkt auf eine Globale variable, gekapselt in einer Methode.

    In deinem Fall ClassToMock umgestaltet werden kann in dieser : 

    public class ClassToMock {
  private static final String MEMBER_1 = FileReader.readMemeber1();

  public String getMemberOne() {
    return MEMBER_1;      
  }
}

    dann kannst du einfach mit Hilfe von Mockito zu verspotten getMemberOne().

    AKTUALISIERT Alten Schritt 1 kann nicht garantieren Mockito mock sicher, wenn FileReader.readMemeber1() Ausnahme auslösen, dann wird der test failled kläglich. So schlage ich vor, einen weiteren Schritt hinzuzufügen, um um ihn zu arbeiten.

    Schritt 1.5. hinzufügen der Setter-und Lazy-Getter

    Da das problem ist FileReader.readMember1() wird aufgerufen, sobald ClassToMock geladen wird. Wir haben, um es zu verzögern. So machen wir die getter-Aufruf FileReader.readMember1() träge, und öffnen Sie ein setter.

    public class ClassToMock {
  private static String MEMBER_1 = null;

  protected String getMemberOne() {
    if (MEMBER_1 == null) {
      MEMBER_1 = FileReader.readMemeber1();
    }
    return MEMBER_1;      
  }

  public void setMemberOne(String memberOne) {
    MEMBER_1 = memberOne;
  }
}

    Nun sollten Sie in der Lage, eine gefälschte ClassToMock auch ohne Mockito. Dies sollte jedoch nicht der Letzte Stand des Codes, sobald Sie Ihren test bereit, sollten Sie mit Schritt 2 fortfahren.

    Schritt 2. Abhängigkeit Injektion

    Sobald Sie Ihren test bereit, Sie sollten es umgestalten weitere mehr. Jetzt zu Lesen, Anstatt die MEMBER_1 von selbst. Diese Klasse sollte erhalten die MEMBER_1 von der Außenwelt statt. Sie können entweder einen setter oder Konstruktor, um es zu empfangen. Unten ist der code, die Verwendung von setter.

    public class ClassToMock {
  private String memberOne;
  public void setMemberOne(String memberOne) {
    this.memberOne = memberOne;
  }

  public String getMemberOne() {
    return memberOne;
  }
}

    Dieser zwei-Schritt-refactorings sind wirklich einfach zu tun, und Sie können es tun, auch ohne test in die hand. Wenn der code ist nicht so Komplex sind, können Sie nur Schritt 2. Dann können Sie ganz einfach testen ClassToTest

    UPDATE 12/8 : Antwort der Kommentar

    Siehe meine andere Antwort in dieser Frage.

    • Ich wäre für Konstruktor-Injektion, wenn möglich, wie es nicht brechen OOP-Prinzipien, und lassen Sie sich nicht Objekt der Hälfte einmal initialisiert erstellt (mit einer no-arg-Konstruktor). Doch diese Schritte sind der Weg zu gehen !
    • Finde ich eigentlich aus Schritt1 nicht garantieren Mocktio mock richtig. Ich füge einen weiteren Schritt zur Umgehung des Problems.
    • Was ist, wenn FileReader ist etwas sehr grundlegendes, wie die Protokollierung werden muss, dass es in jeder Klasse. Würden Sie vorschlagen, ich verfolge den gleichen Ansatz gibt es?
    • In diesem Fall würde ich vorschlagen, Sie einen anderen Weg. Bitte Lesen Sie meine andere Antwort.
    InformationsquelleAutor Rangi Lin
  2. 3

    UPDATE 12/8 : Antwort der Kommentar

    Frage : Was ist, wenn FileReader ist etwas sehr grundlegendes, wie die Protokollierung muss
    es werden in jeder Klasse. Würden Sie vorschlagen, ich verfolge den gleichen Ansatz
    es?

    Es hängt davon ab.

    Gibt es etwas, was Sie wollen, zu denken, bevor Sie tun eine massive Umgestaltung so.

    1. Wenn ich mich bewege FileReader außerhalb, habe ich eine geeignete Klasse zum Lesen aus der Datei und geben Sie das Ergebnis jede einzelne Klasse, die Sie braucht ?

    2. Neben making-Klassen einfacher zu testen, erhalte ich andere Vorteile ?

    3. Habe ich Zeit ?

    Wenn eine der Antworten "NEIN" ist, dann sollten Sie besser nicht.

    Jedoch, wir können immer noch brechen die Abhängigkeit zwischen den Klassen und FileReader mit minimalen änderungen.

    Ihre Frage und einen Kommentar, ich nehme an, Ihr system mit FileReader als Globale Referenz für lesestoff aus einer properties-Datei, dann geben Sie Sie an den rest des Systems.

    Diese Technik wird auch eingeführt in Michael Feathers ' s wunderbares Buch : Working effectively with Legacy Code, wieder.

    Schritt 1. Delegieren FileReader statische Methoden zum Beispiel.

    Ändern 

    public class FileReader {
  public static FileReader getMemberOne() {
    //codes that read file.
  }
}

    Zu

    public class FileReader {
  private static FileReader singleton = new FileReader();
  public static String getMemberOne() {
    return singleton.getMemberOne();
  }

  public String getMemberOne() {
    //codes that read file.
  }
}

    Dadurch werden statische Methoden in FileReader jetzt keine Kenntnis darüber, wie getMemberOne()

    Schritt 2. Interface extrahieren von FileReader

    public interface AppProperties {
  String getMemberOne();
}

public class FileReader implements AppProperties {
  private static AppProperties singleton = new FileReader();
  public static String getMemberOne() {
    return singleton.getMemberOne();
  }

  @Override
  public String getMemberOne() {
    //codes that read file.
  }
}

    Wir alle extrahieren der Methode AppProperties und statische Instanz in FileReader jetzt mit AppProperties.

    Schritt 3. Statische setter -

    public class FileReader implements AppProperties {
  private static AppProperties singleton = new FileReader();

  public static void setAppProperties(AppProperties prop) {
    singleton = prop;
  }

  ...
  ...
}

    Eröffneten wir eine Naht in der FileReader. Indem wir dies tun, können wir ändern die zugrunde liegenden Instanz in FileReader und es würde nie auffallen.

    Schritt 4. Clean up

    Nun FileReader haben zwei Aufgaben. Ist man Dateien Lesen und geben das Ergebnis ein anderes ist ein globaler Verweis für system.

    Können wir trennen Sie und geben Ihnen eine gute Namensgebung. Hier ist das Ergebnis :

    //This is the original FileReader, 
//now is a AppProperties subclass which read properties from file.
public FileAppProperties implements AppProperties {
  //implementation.
}

//This is the class that provide static methods.
public class GlobalAppProperties {

  private static AppProperties singleton = new FileAppProperties();

  public static void setAppProperties(AppProperties prop) {
    singleton = prop;
  }

  public static String getMemberOne() {
    return singleton.getMemberOne();
  }
  ...
  ...
}

    ENDE.

    Nach diesem refactoring, Wann immer Sie wollen zu testen. Sie können einen mock AppProperties zu GlobalAppProperties

    Denke ich, dass diese Umgestaltung besser wäre, wenn alles, was Sie tun möchten, brechen Sie die gleichen globalen Abhängigkeit in vielen Klassen.

    InformationsquelleAutor Rangi Lin
Schreibe einen Kommentar