如何获得“差异” Java 中的数组之间
我正在尝试为某些类编写一些测试用例，其中涉及测试二维数据数组的相等性。这是我的第一次尝试：
double[][] expected = {
{0, 104, 0},
{145.5, 0, 0},
{83, 0, 0}
};
double[][] actual = someObject.getArray();
现在，我看到 JUnit 没有用于双精度数组的“arrayEquals”，可能是由于浮点问题（您确实想使用增量与相等）。我注意到 Junit-Addons 正是我需要确定的方法如果它们相等：
static void assertEquals(java.lang.String message, double[] expected, double[] actual, double delta)
现在，一切都很好。我想要做的是给出一个有意义的错误消息，不仅仅是说两者不相等，而是说它们在哪里不相等。有没有一种简单的方法可以做到这一点，无需比较维度，然后迭代每个相应的元素并测试相等性？必须做与断言中所做的相同的事情，只是为了获得有意义的错误消息，这似乎很愚蠢。
I am attempting to write some test cases for some classes that involve testing the equality of two dimensional arrays of data. Here is my first stab at it:
double[][] expected = {
{0, 104, 0},
{145.5, 0, 0},
{83, 0, 0}
};
double[][] actual = someObject.getArray();
Now, I see that JUnit does not have an 'arrayEquals' for double arrays, probably due to the floating point issue (you really want to use a delta vs equality). I notice that Junit-Addons has exactly the method I need to determine if they're equal:
static void assertEquals(java.lang.String message, double[] expected, double[] actual, double delta)
Now, that's all well and fine. What I want to be able to do is give a meaningful error message, not just saying that the two are unequal but where they are unequal. Is there an easy way of doing this, short of comparing dimensions, then iterating over each corresponding element and testing for equality? It seems silly to have to do the same thing that's being done in the assertion, just to get a meaningful error message.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为您将单元测试与仪器/调试混为一谈。单元测试的目的是确定您的对象是否按预期工作。如果您养成在测试用例中包含（有效）检测的代码的习惯，那么您编写旨在通过的测试用例的可能性就会增加。
您的对象有一个返回
double[][]的方法。您的测试用例告诉您它没有按预期工作。是时候调试您的代码了。（我知道这可能是一个有争议的观点。）
I would think that you are conflating unit testing with instrumentation/debugging. The purpose of the unit test is to determine if your object works as expected. If you get into the habit of including code that is (effectively) instrumentation in your test cases, you increase the probability that you will write test cases that are designed to pass.
Your object has a method that is to return a
double[][]. Your test case is telling you that it is not working as expected. Time to debug your code.(I understand that this may be a controversial point of view.)
那么，您是想比较 double[] 还是 double[][] ？
如果您要比较 double[]（一维数组），那么是的，使用 Junit-Addons 怎么样？它的默认错误消息不是您需要的吗？如果您能够编写测试来使用 Double[]，那么 JUnit 的对 Object[] 进行操作的assertArraysEquals() 方法将起作用。不过，它会比较双精度数是否完全相等——假设这就是您的意图。
如果您要比较 double[][]，那么这些都不起作用。即使 double[][] 是一个 Object[]，您也不打算比较各个 double[]，因为它们只是使用引用相等性。
您可以使用 commons-lang 进行比较，这是真的，尽管它不会帮助您生成有关差异所在的有用消息。为此，我认为您需要推出自己的方法。
So, are you trying to compare double[]s or double[][]s?
If you are comparing double[]s (1D arrays), then yeah, how about using Junit-Addons? is its default error message not what you need? If you are able to write your tests to use Double[] instead, then JUnit's assertArraysEquals() method which operates on Object[] will work. It will compare doubles for exact equality though -- assuming that's what you intend.
If you're comparing double[][], then neither of these work. Even though double[][] is an Object[], you don't intend to compare individual double[]s since they just use reference equality.
You can use commons-lang to do the comparison, true, though it won't help you generate a useful message about where the difference is. For that, I think you need to roll your own method.
我说得对吗？除了输出之外，您对 JUnit-Addons 中的 assertEquals(String, double[], double[], double) 方法感到满意吗？
假设您拥有或可以获得 ArrayAssert 类的源代码，只需重新实现该方法（复制并粘贴，但首先检查许可证）并根据您的需要增强新的自定义 assertEquals 方法中的输出。我想，不会花太长时间的！
Do I get it right, you're happy with the assertEquals(String, double[], double[], double) method from JUnit-Addons except for the output?
Assuming, you have or can get the source of the ArrayAssert class, just reimplement the method (copy&paste but check the license first) and enhance the outputs in the new custom assertEquals method to your needs. I think, it won't take too long!