Java JUnit: Die Methode X ist mehrdeutig für Typ Y

Lesezeit: 4 Minuten

Benutzer-Avatar
Nik Heiner

Ich hatte einige Tests, die gut funktionierten. Dann habe ich es in ein anderes Paket verschoben und erhalte jetzt Fehler. Hier ist der Code:

import static org.junit.Assert.*;
import java.util.HashSet;
import java.util.Map;
import java.util.Set;

import org.jgrapht.Graphs;
import org.jgrapht.WeightedGraph;
import org.jgrapht.graph.DefaultWeightedEdge;
import org.jgrapht.graph.SimpleWeightedGraph;
import org.junit.*; 

@Test
    public void testEccentricity() {
        WeightedGraph<String, DefaultWeightedEdge> g = generateSimpleCaseGraph();
        Map<String, Double> eccen = JGraphtUtilities.eccentricities(g);

        assertEquals(70, eccen.get("alpha"));
        assertEquals(80, eccen.get("l"));
        assertEquals(130, eccen.get("l-0"));
        assertEquals(100, eccen.get("l-1"));
        assertEquals(90, eccen.get("r"));
        assertEquals(120, eccen.get("r-0"));
        assertEquals(130, eccen.get("r-1"));
    }

Die Fehlermeldung ist diese:

Die Methode assertEquals(Object, Object) ist für den Typ JGraphtUtilitiesTest mehrdeutig

Wie kann ich das beheben? Warum ist dieses Problem aufgetreten, als ich die Klasse in ein anderes Paket verschoben habe?

  • sagen Sie uns, wie Ihre Klasse deklariert ist. Sieht für mich so aus, als hättest du von JUnit3 geerbt und dann versucht, statisch von JUnit4 zu importieren.

    – bmargulies

    28. November 2009 um 0:32 Uhr

  • Ja, eigentlich hatte ich JUnit3 in Paket A und benutzte JUnit4 in Paket B, wo ich ursprünglich diese Tests geschrieben habe. Dann wechselte ich von Paket B zu Paket A, und das Problem trat auf. Aber ich sehe in dieser Klasse nichts, was auf JUnit 3 hindeuten würde. Wo ist das deklariert?

    – Nick Heiner

    28. November 2009 um 0:38 Uhr

  • @Rosarch Sind diese JGraphtUtilities überall verfügbar? Ich kann keine Methoden sehen, um Exzentrizitäten in JGraphT zu erzeugen!

    – Nik

    13. Dezember 2012 um 12:17 Uhr

Benutzer-Avatar
Pascal Thivent

Die Methode assertEquals(Object, Object) ist mehrdeutig für den Typ …

Dieser Fehler bedeutet, dass Sie eine übergeben double und und Double in eine Methode mit zwei unterschiedlichen Signaturen: assertEquals(Object, Object) und assertEquals(double, double) beide konnten dank Autoboxing aufgerufen werden.

Um Zweideutigkeiten zu vermeiden, stellen Sie sicher, dass Sie entweder anrufen assertEquals(Object, Object) (durch Passieren von zwei Doubles) oder assertEquals(double, double) (durch Passieren von zwei Doubles).

In Ihrem Fall sollten Sie also Folgendes verwenden:

assertEquals(Double.valueOf(70), eccen.get("alpha"));

Oder:

assertEquals(70.0d, eccen.get("alpha").doubleValue());

  • ok, oder ich könnte es einfach auf JUnit 4 anstelle von JUnit 3 umstellen. Wie mache ich das?

    – Nick Heiner

    28. November 2009 um 1:38 Uhr

  • Die Lösung besteht nicht wirklich darin, von einer Version zur anderen zu wechseln. Helfen Sie stattdessen dem Compiler und entfernen Sie die Mehrdeutigkeit, wie ich vorgeschlagen habe.

    – Pascal Thivent

    28. November 2009 um 2:55 Uhr

  • Wie auch immer, sollte es nicht assertEquals(70.0d, eccen.get(“alpha”)); ?

    – Müller

    28. November 2009 um 3:06 Uhr

  • @mahller Ich bin mir nicht sicher, mit wem Sie sprechen, aber selbst wenn es korrekter ist als der Code des OP, ist es immer noch nicht eindeutig, ob die Version von JUnit beides hat assertEquals(Object, Object) und assertEquals(double, double) was bei JUnit 4.4, 4.5 der Fall ist. Aber wie gesagt, das Ändern der Version von JUnit ist nicht die wirkliche Lösung, sondern nur das Problem beheben.

    – Pascal Thivent

    28. November 2009 um 5:58 Uhr

  • @Rosarch Für diesen speziellen Fall ist es kein Problem in JUnit 3.8.1, es ist kein Problem in JUnit 4.3, it ist ein Problem in JUnit 4.4, es ist ein Problem in JUnit 4.5 (aber die Methode, die 2 Doubles nimmt, ist veraltet), es ist kein Problem in JUnit 4.6 (die Methode wurde entfernt). Treffen Sie also Ihre Wahl, aber Sie sollten den Code korrigieren.

    – Pascal Thivent

    28. November 2009 um 5:59 Uhr

Benutzer-Avatar
Franz Marzoa

Die einfachste Lösung für dieses Problem besteht darin, den zweiten Parameter einfach in ein Primitiv umzuwandeln:

assertEquals(70, (double)eccen.get("alpha"));

Mehrdeutigkeit beseitigt.

Dies gilt für alle Number-Unterklassen, zum Beispiel:

assertEquals(70, (int)new Integer(70));

Würde auch eine Unklarheit lösen.

Allerdings ist assertEquals(double, double) ab sofort aus guten Gründen veraltet, daher empfehle ich Ihnen, die Methode mit einem Delta zu verwenden, wie andere bereits vorgeschlagen haben.

Mit guten Gründen meine ich, dass sich angesichts der inneren Darstellung von Doppelzahlen zwei scheinbar gleiche Doppelzahlen in einem irrelevanten infinitesimalen Bruch unterscheiden können und einen Test nicht bestehen würden, aber das bedeutet nicht, dass etwas mit Ihrem Code nicht stimmt.

Benutzer-Avatar
Paolo

Sie können die Methode verwenden

assertEquals(double expected, double actual, double delta)

Dabei werden Rundungsfehler berücksichtigt, die Gleitkommazahlen inhärent sind (siehe zum Beispiel diesen Beitrag). Du kannst schreiben

assertEquals(70, eccen.get("alpha"), 0.0001);

Das heißt, solange sich die beiden Werte um weniger als 0,0001 unterscheiden, gelten sie als gleich. Dies hat zwei Vorteile:

  • Vergleicht Fließkommawerte wie vorgesehen
  • Casting ist nicht erforderlich, da die Behauptung mit drei Argumenten nur für Doubles gilt, nicht für generische Objekte

1298920cookie-checkJava JUnit: Die Methode X ist mehrdeutig für Typ Y

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy