Java JUnit: วิธี X ไม่ชัดเจนสำหรับประเภท Y


98

ฉันมีการทดสอบบางอย่างที่ทำงานได้ดี จากนั้นฉันย้ายไปยังแพ็คเกจอื่นและตอนนี้ได้รับข้อผิดพลาด นี่คือรหัส:

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"));
    }

ข้อความแสดงข้อผิดพลาดคือ:

เมธอด assertEquals (Object, Object) ไม่ชัดเจนสำหรับชนิด JGraphtUtilitiesTest

ฉันจะแก้ไขปัญหานี้ได้อย่างไร? เหตุใดปัญหานี้จึงเกิดขึ้นเมื่อฉันย้ายชั้นเรียนไปยังแพ็คเกจอื่น


บอกเราว่าชั้นเรียนของคุณได้รับการประกาศอย่างไร ดูเหมือนว่าฉันจะได้รับมรดกจาก JUnit3 แล้วพยายามนำเข้าจาก JUnit4 แบบคงที่
bmargulies

ใช่จริงๆแล้วฉันมี JUnit3 ในแพ็คเกจ A และใช้ JUnit4 ในแพ็คเกจ B ซึ่งตอนแรกฉันเขียนการทดสอบเหล่านี้ จากนั้นฉันก็เปลี่ยนจากแพ็คเกจ B เป็นแพ็คเกจ A และปัญหาก็เกิดขึ้น แต่ฉันไม่เห็นอะไรในคลาสนี้ที่บ่งบอกถึง JUnit 3 ที่ประกาศ?
Nick Heiner

@Rosarch JGraphtUtilities เหล่านี้สามารถใช้ได้ทุกที่หรือไม่? ฉันไม่เห็นวิธีการสร้างความผิดปกติใน JGraphT!
นิค

คำตอบ:


205

เมธอด assertEquals (Object, Object) ไม่ชัดเจนสำหรับประเภท ...

ข้อผิดพลาดนี้หมายความว่าคุณกำลังส่งdoubleและDoubleเข้าสู่เมธอดที่มีลายเซ็นสองแบบที่แตกต่างกันassertEquals(Object, Object)และassertEquals(double, double)ทั้งสองอย่างนี้สามารถเรียกได้ด้วยการทำกล่องอัตโนมัติ

เพื่อหลีกเลี่ยงความคลุมเครือตรวจสอบให้แน่ใจว่าคุณโทรassertEquals(Object, Object)(โดยผ่านสองคู่) หรือassertEquals(double, double)(โดยผ่านสองคู่)

ดังนั้นในกรณีของคุณคุณควรใช้:

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

หรือ:

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

โอเคหรือฉันสามารถเปลี่ยนไปใช้ JUnit 4 แทน JUnit 3 ได้อย่างไร
Nick Heiner

8
วิธีแก้ปัญหาไม่ใช่การเปลี่ยนจากเวอร์ชันหนึ่งไปเป็นอีกเวอร์ชันหนึ่ง ให้ช่วยคอมไพเลอร์และลบความคลุมเครือตามที่ฉันแนะนำ
Pascal Thivent

1
อย่างไรก็ตามไม่ควรเป็น assertEquals (70.0d, eccen.get ("alpha")); เหรอ?
mhaller

3
@mahller ไม่แน่ใจว่าคุณกำลังคุยกับใคร แต่แม้ว่าจะถูกต้องมากกว่ารหัสของ OP แต่ก็ยังคงคลุมเครือหาก JUnit เวอร์ชันมีทั้งสองอย่างassertEquals(Object, Object)และassertEquals(double, double)เป็นกรณีของ JUnit 4.4, 4.5 แต่อย่างที่บอกว่าการเปลี่ยนเวอร์ชันของ JUnit ไม่ใช่ทางออกที่แท้จริงเพียงแค่แก้ไขปัญหา
Pascal Thivent

1
@Rosarch สำหรับกรณีนี้ไม่มีปัญหาใน JUnit 3.8.1 ไม่ใช่ปัญหาใน JUnit 4.3 เป็นปัญหาใน JUnit 4.4 เป็นปัญหาใน JUnit 4.5 (แต่วิธีการใช้ 2 doubles เลิกใช้งานแล้ว) ไม่มีปัญหาใน JUnit 4.6 (วิธีนี้ถูกลบออกไปแล้ว) ดังนั้นให้คุณเลือก แต่คุณควรแก้ไขโค้ด
Pascal Thivent

1

คุณสามารถใช้วิธี

assertEquals(double expected, double actual, double delta)

ซึ่งจะคำนึงถึงข้อผิดพลาดในการปัดเศษที่ hinerent ไปยังทศนิยม (ดูโพสต์นี้เป็นต้น) คุณสามารถเขียน

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

ซึ่งหมายความว่าตราบใดที่ทั้งสองค่าต่างกันน้อยกว่า 0.0001 ค่าเหล่านี้จะถือว่าเท่ากัน สิ่งนี้มีข้อดีสองประการ:

  • เปรียบเทียบค่าทศนิยมตามที่ควรจะเป็น
  • ไม่จำเป็นต้องแคสต์เนื่องจากอาร์กิวเมนต์สามข้อยืนยันจะใช้กับการเพิ่มเป็นสองเท่าเท่านั้นไม่ใช่กับวัตถุทั่วไป

0

วิธีแก้ปัญหาที่ง่ายที่สุดคือเพียงแค่ส่งพารามิเตอร์ที่สองลงในแบบดั้งเดิม:

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

ลบความคลุมเครือ

สิ่งนี้ใช้ได้สำหรับคลาสย่อย Number ใด ๆ ตัวอย่างเช่น:

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

จะแก้ความกำกวมด้วย

อย่างไรก็ตาม assertEquals (double, double) เลิกใช้งานแล้วในตอนนี้และด้วยเหตุผลที่ดีดังนั้นฉันขอแนะนำให้คุณใช้วิธีนี้กับเดลต้าตามที่คนอื่นแนะนำไปแล้ว

ด้วยเหตุผลที่ดีฉันหมายความว่าจากการแทนค่าภายในของจำนวนคู่ตัวเลขสองเท่าที่เห็นได้ชัดว่าสองจำนวนเท่ากันอาจแตกต่างกันในเศษส่วนน้อยที่สุดที่ไม่เกี่ยวข้องและจะไม่ผ่านการทดสอบ แต่นั่นไม่ได้หมายความว่ามีอะไรผิดปกติกับรหัสของคุณ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.