LocalDateTime testen mit Junit

[JavaExpInc]

Hallo zusammen,

ich weiß momentan leider nicht wie ich mein LocalDateTime testen kann.
Momentan sieht meine Klasse so aus.

public class testclass(){
public testclass(){
this.setCreationDate();
}

    public LocalDateTime getCreationDate() {
        return creationDate;
    }
    public void setCreationDate() {
        this.creationDate = LocalDateTime.now();
    }
}

Momentan bekomme ich die Fehlermeldung, das ich die beiden CreationDates die ich vergleiche nicht gleich sind (um ein paar Millisekunden). Weil das eine etwas später erstellt wird als das andere. Nur wie teste ich so etwas?

 

[JavaExpInc]

Hab es gerade mal auf dieses hier umgeändert:

public class testClass{
 public testClass(){
 setCreationDate(LocalDateTime.now());
}
    public LocalDateTime getCreationDate() {
        return creationDate;
    }
    public void setCreationDate(LocalDateTime date) {
        this.creationDate = LocalDateTime.now();
    }
}

Nun funktioniert mein Test. Macht man es generell eher so? Habe gedacht die SetMethode müsste nun anders aussehen da ich sonst später ja von meiner Klasse das Datum abändern kann wobei man das erstellungsdatum ja nicht abändern sollen könnte.

 

[mrBrown]

Das ist doch nicht mal gültiger Java-Code?
Das sind auch nur ein (falscher) Setter und ein Getter, wo soll da irgendwas getestet werden?

 

[JavaExpInc]

Doch das ist gültiger Java-Code

Wie erstelle ich denn nun den Setter richtig für das CreationDate? Das ist ja auch meine Frage, eigtl dürfe der nicht so wie bei mir sein weil man nicht übergeben soll, da man es sonst später nocheinmal aufrufen kann. Aber wenn ich es so mache wie am Anfang, weiß ich nicht wie ich es testen soll.

Hier der aktuelle Test

@Test
public void test(){
testClass t = new testClass();
LocalDateTime tmp = LocalDateTime.now();
t.setCreationDate(tmp);
assertEquals("creationDate not correct", tmp, t.getCreationDate());

 

[Robat]

Mal zum Setter:
Du übergibst doch das neue LocalDateTime-Objekt schon als Parameter im Setter .. jetzt musst du nur noch das alte mit dem neuen überschreiben ..

Das wird aber noch nicht reichen. Deine testClass muss das LocalDateObjekt im Konstruktror übergeben bekommen .. ansonsten wird es nie das selbe Objekt (Datum) sein, da (wie du schon sagtest) sonst kleine Abweichungen vorliegen.

 

[mrBrown]

Doch das ist gültiger Java-Code

Nö, das: public class testclass(){ ist sicherlich keine gültige Klassendeklaration.

Und in diesem Code:

public class testClass{
 public testClass(){
 setCreationDate(LocalDateTime.now());
}
    public LocalDateTime getCreationDate() {
        return creationDate;
    }
    public void setCreationDate(LocalDateTime date) {
        this.creationDate = LocalDateTime.now();
    }
}

gibt es this.creationDate nicht.



Für den Test wäre es gut, erstmal das gewünschte Verhalten zu kennen.
Soll es einen öffentlichen Setter (und damit die Möglichkeit zum Ändern) geben oder nicht?
Oder soll das CreationDate bei erstellen der Klasse festgelegt werden?

 

[JavaExpInc]

@mrBrown
Okay da hast du recht, da hab ich mich hier im Forum wohl vertippt gehabt
Es soll kein öffentlicher Setter sein, da mein Erstelldatum nur einmalig beim erstellen des Objektes gesetzt werden soll und danach nicht mehr.

@Robat
Es soll ja nicht überschrieben werden, da es nur einmalig genutzt werden soll wenn die Klasse erstellt wird. Danach soll man das creationDate nicht mehr verändern.

 

[mrBrown]

Dann übergib es doch einfach dem Konstruktor?

 

[JavaExpInc]

public class testClass{
 public testClass(LocalDateTime LocalDateTime.now()){
this.creationDate = LocalDateTime.now())
}
    public LocalDateTime getCreationDate() {
        return creationDate;
   }
}

Meinst du so? Und dann halt ohne Setter Methode sondern nur mit Getter Methode?

 

[mrBrown]

Wenn du jetzt noch aus dem Parameter einen Parameter machst, und den dann auch nutzt...

 

[JavaExpInc]

Mh Ich glaube ich stehe wieder auf dem Schlauch.

public class testClass{
 public testClass(LocalDateTime date){
this.creationDate = date;
}
    public LocalDateTime getCreationDate() {
        return creationDate;
   }
}

Du meinst das ja so oder? Jedoch soll dieses Objekt in einer grafischen Oberfläche (Webseite & App) ausgefüllt werden - das creationDate soll aber vom System übergeben werden. Wie es jetzt ist müsste der User das ja selber eingeben. Oder wie bewerkstellige ich das dann so, dass es beim reinschreiben in die DB automatisch passiert?

 

[mrBrown]

Der User dieses Objekts ist der Programmierer, also du. Das der Nutzer der Anwendung das nicht angeben muss, sondern das automatisch passiert, ist doch genau dein Job


Wenn das Objekt selbst bestimmen soll, wann es angelegt werden soll, dann musst du now() nutzen - was für diesen Fall die Anforderungen sind, müsstest du aber erst einmal Festlegen

 

[JavaExpInc]

Das Objekt an sich wird von dem Nutzer angelegt über die Webseite. Jedoch gibt er da in dem textfeld ja nicht das Datum an wann er es erstellt -> das soll im Hintergrund automatisch passieren.

Sowie es momentan ist, müsste der Nutzer es ja im Konstruktor selbst mit übergeben. Also bleibt es bei dem wie ich es vorher schon gemacht hatte?! Weil als Konstruktorübergabe müsste der Nutzer der Website es ja selbst bestimmen. Und da die Methode nur einmal aufgerufen werden soll kann ich doch im Konstruktor direkt angeben

public testclass(){
this.creationDate = LocalDateTime.now();
}

Oder?

 

[mrBrown]

Das Objekt an sich wird von dem Nutzer angelegt über die Webseite. Jedoch gibt er da in dem textfeld ja nicht das Datum an wann er es erstellt -> das soll im Hintergrund automatisch passieren.

Sowie es momentan ist, müsste der Nutzer es ja im Konstruktor selbst mit übergeben.

Hast du jemals als Benutzer einer Website direkt einen Konstruktor aufgerufen?

Also bleibt es bei dem wie ich es vorher schon gemacht hatte?! Weil als Konstruktorübergabe müsste der Nutzer der Website es ja selbst bestimmen. Und da die Methode nur einmal aufgerufen werden soll kann ich doch im Konstruktor direkt angeben

public testclass(){
this.creationDate = LocalDateTime.now();
}

Oder?

Du kannst das genausogut dem Konstruktor übergeben, das kommt eben auf die Anforderungen an, die du als Nutzer der API (!= Nutzer der Website) hast.
Wenn dir das so reicht, dann mach es so.

 

[JavaExpInc]

Alles klar, dann habe ich das dort falsch verstanden. Mir fehlt da einfach noch die Erfahrung...

Was hätte es denn für einen Vorteil wenn ich es in den Konstruktor gebe?

 

[mrBrown]

Was hätte es denn für einen Vorteil wenn ich es in den Konstruktor gebe?

Naja, du könntest es testen und verschiebst die Verantwortlichkeit für den Zeitpunkt aus der Klasse heraus.

Das kann Vorteile haben, allerdings auch Nachteile.

 

[JavaExpInc]

Okay dann bleibe ich bei meiner Variation Aber welche sollte ich denn jz nehmen?

1.

public testClass(){
creationDate = LocalDateTime.now();
}

2.

public testClass(){
this.setCreationDate();
}

natürlich immer mit der GetMethode.

 

[mrBrown]

Setter nur, wenn man es nachträglich andern soll, ansonsten final nutzen.

 

[JavaExpInc]

dann würde ich es so machen?

public class testclass{
private final creationDate;

public testclass(){
creationDate = LocalDateTime.now();
}
}

 

[JavaExpInc]

Nur dann gibt es keine Möglichkeit das zu testen oder?

 

[mrBrown]

Keine, die mit equals vergleichen kann, dafür musst du eben irgendwas übergeben.

Du kannst aber, wenn nicht auf den genauen Zeitpunkt getestet werden muss, die Zeit vor und nach dem Konstruktor-Aufruf merken, und dann prüfen, ob creationDate dazwischen liegt.

Ein anderer Weg wäre, eine Clock zu übergeben, dann müsste man aber wieder was übergeben.