AnyString() als parameter für unit-test

Gut, wie Mockito ist versucht zu sagen, über diese Ausnahme, das ist nicht wirklich, wie Sie möchten, verwenden anyString. Solche Methoden sind nur für die Verwendung durch verspottet.

Also, warum nicht versuchen, testen, mit einem tatsächlichen random string? Mein persönlicher Favorit in einem solchen Szenario: java.util.UUID.randomUUID().toString(). Dies wird praktisch immer erzeugen Sie eine Marke neue Zeichenfolge, die noch nie verwendet wurde für den test vor.

Ich möchte auch hinzufügen, dass, wenn Sie schreiben tests für Ihre SomeObject Klasse, die Sie vermeiden sollten mocking SomeObject's Verhalten. Von Ihrem Beispiel, Sie waren nicht gerade gut, aber es sah aus wie Sie sein könnte, geht unter, die route. Spotten die Abhängigkeiten von der Implementierung, Sie versuchen zu testen, nicht die Umsetzung selbst! Dies ist sehr wichtig; andernfalls sind Sie nicht wirklich testen, nichts.

InformationsquelleAutor nasukkin

Mischen Sie Konzepte hier.

All diesen "Spott" Helfer wie anyString() werden sollte verwendet werden, wenn die Konfiguration eines mock Objekt.

Aber wenn Sie überprüfen Ihre Prüfung code:

@Test(expected = RuntimeException.class)
public void ifOtherObjectIsNullExpectRuntimeException() {
  myTestObject.doSomething(null, "testString");
}

werden Sie finden: es ist absolut keine Verspottung beteiligten für diesen test. Sie einfach nicht verwenden Sie diejenigen, die Mokito fordert in diesem Ort; denn "es gibt keine Mokito".

Und nur für das Protokoll - keine Notwendigkeit, über Bord gehen hier sowieso. Ihre Logik ist hier sehr deutlich: wenn das erste argument null ist, dann Sie werfen der Ausnahme. Also es ist wirklich egal, was kommt, als zweites argument. Also, denken Sie für eine Stunde, wie um zu testen, null mit jeder zweiten argument ist, nun, in meinen Augen: Verschwendung von Ihrer Zeit.

Letzte Tipp: es gibt java.lang.Objekte
Und diese Klasse hat einen schönen check für null, so dass meine Produktion code sieht nur aus wie

public SomeObject doSomething(final OtherObject x, final String something) {
  Objects.requireNonNull(otherObject, "otherObject must not be null");
  Objects.requireNonNull(something, "something must not be null");

Einzige Unterschied: erfordert... wirft NullPointerExceptions

Finale schließlich: einige Menschen behaupten zu setzen, endgültig auf alle parameter; aber ich würde das nicht tun. Es fügt keine Wert in 99% aller Fälle. Es bedeutet nur, dass Sie mehr code zu Lesen; für keine gibt es gute Gründe. Aber das ist eine Frage des Stils.

BEARBEITEN auf den Kommentar darüber, dass ein test, um zu überprüfen, für mögliche zukünftige änderungen: Sie sollte das nicht tun:

1. Bis zu einem gewissen Grad, wie Sie Ihre Eingabe geprüft ist, ist eine Implementierung detail. Sie testen nicht für Implementierungsdetails. In anderen Worten:
2. Ihre Methode hat einen bestimmten Vertrag (die Sie zum Beispiel angeben, informell durch das schreiben von javadoc, die sagt "wirft NPE on null input"). Die tests sollten überprüfen, genau, dass Sie den aktuellen Vertrag. Und der Vertrag löst, wenn das erste argument null ist.

Und vielleicht eine andere Sicht; wie ich denke immer noch, Sie verschwenden Ihre Zeit hier! Sie sollten sicherstellen, dass alle Schnittstellen sind klar, einfach zu verstehen und einfach zu bedienen. Sie können die Benutzer von Ihrem code das richtige zu tun, einfach; und ihn davon abhalten, das falsche zu tun. Das ist das, was Sie sich konzentrieren sollten auf die Qualität Ihrer Schnittstellen als ganzes!
Also anstatt sich Gedanken, wie Sie schreiben, könnte ein test für mögliche zukünftige Veränderungen; so stellen Sie sicher, dass Ihre code-Basis ist insgesamt konsistent.

InformationsquelleAutor GhostCat