Unit Test - Abgänigkeit zur Datenbank isolieren

[looparda]

Hallo, ich beschäftige mich gerade mit unit tests und finde keinen Ansatz für folgendes Problem:
Ein Parser soll einen Rezepttext in ein Rezept wandeln und zurückgeben.

public class Parser {
    public IRecipe parse(String text) {
        IRecipe recipe = IRecipe.getInstance();
        recipe.setTitle("Sample Title");
        recipe.add("Reis", 200, "g");
        return recipe;
    }
}

public interface IRecipe {
    static IRecipe getInstance() {
        return new Recipe(); // Recipe erbt von einer ORM-Library, alle Funktionen des Interfaces IRecipe machen Datenbank-Zugriffe in Recipe.
    }
    boolean saveIt();
    String getTitle();
    long getID();
    void setTitle(String title);
    void add(IRecipeIngredient recipeIngredient);
    void add(String ingredientName, int amount, String unitName);
    Map<IIngredient, Map<Integer, IUnit>> getIngredients();
}

Jetzt möchte ich jedoch den Parser testen:

@Test
public void theParsedRecipeHasProperIngredients() {
    final List<String> ingredientNames = exampleRecipe
        .getIngredients()
        .keySet()
        .stream()
        .map(iIngredient -> iIngredient.getName())
        .collect(Collectors.toList());

    the(ingredientNames).shouldContain("Reis");
}

Problem: recipe.setTitle() und recipe.add(), recipe.getIngredients() usw. greifen in der Implementierung in Recipe auf die Datenbank zu. Das möchte ich beim Testen nicht.
Mein Ansatz wäre: Ich muss IRecipe.getInstance(); so bauen, dass es einen Mock zurückgibt, wenn die Tests ausgeführt werden und die "normale" Implementierung wenn es sich nicht um einen Test handelt.
Wie gehe ich vor um die Abhängigkeit zur Datenbank zu isolieren?

 

[looparda]

Ich könnte auch dem Parser ein Objekt vom Typ IRecipe übergeben, mit dem er arbeiten soll. (ich denke Dependency Injection). Jedoch ergibt diese Änderung allein an der Signatur keinen Sinn, bzw. sieht falsch aus.

public IRecipe parse(IRecipe recipe, String text)

Und vorher per Konstruktor übergeben? Weiß nicht. Brauche jemanden mit Erfahrung, der hilft.

 

[mrBrown]

Du musst Interface und Implementation trennen, so wie es aktuell ist, ist das Interface ja an die Implemenation gekoppelt.

Ich würde würde statt der getInstance-Methode einen Builder benutzen, ggf mit Interface, der dem Pariser übergeben wird. In den Tests übergibt man dann einen anderen Builder, der eine IRecipe-Instanz ohne DB-Abhängigkeit erstellt.

Als Beispiel:

public interface IRecipeBuilder {
IRecipe getInstance();
}

public class DBRecipeBuilder {
@Override
IRecipe getInstance(){
       return new Recipe();
   }
} //Das gleiche für IRecipeImpl ohne DB-Abhängigkeit

public class Parser {
  private IRecipeBuilder builder; //Setzten über Setter,Konstruktor etc. oder erst über Methodenargument

   public IRecipe parse(String text /*,IRecipeBuilder builder*/){
        IRecipe recipe = builder.getInstance();
        recipe.setTitle("Sample Title");
        recipe.add("Reis", 200, "g");
       return recipe;
   }
}

In Programm und Tests übergibt man dann jeweils den passenden Builder.

Edit:

Andere Möglichkeit wäre, Perser abstrakt zu machen, darin eine abstrakte getInstance, fürs Programm wird das dann so implementiert, das IRecipe.getInstance benutzt wird, in den Tests gibts dann eine Test-Implementierung von IRecipe zurück

 

[looparda]

Du musst Interface und Implementation trennen, so wie es aktuell ist, ist das Interface ja an die Implemenation gekoppelt.

Genau, es war so gedacht, die Referenz auf die konkrete Implementierung an genau einer Stelle ändern zu müssen, falls man später eine zweite Implementierung einführt, die benutzt werden soll. Leider war da noch nicht bedacht, dass ich dennoch eine 2. Implementierungen benötige für den Test.

Andere Möglichkeit wäre, Perser abstrakt zu machen, darin eine abstrakte getInstance, fürs Programm wird das dann so implementiert, das IRecipe.getInstance benutzt wird, in den Tests gibts dann eine Test-Implementierung von IRecipe zurück

Der Parser hat tatsächlich eine Abstrakte Klasse, die ich hier zur Vereinfachung weggelassen habe. Du meinst ich habe dann 2 Subtypen, jeweils normal und für Tests? Dies wäre auch mit einer protected und nur einem Subtypen möglich, der dann diese Funktion überschreibt und einen Fake zurückgibt. Jenes ist mir dann als Seam bekannt.
Ich denke ich versuche es mit dem Builder.