为大型数据结构编写单元测试
假设您有一个方法 Tree supersizeMe(Tree input) 。输入和返回值都是递归数据结构，并且该方法返回一个大小因子约为 500 的结构。因此，如果 input 是可能的最小元素，则该函数的返回值包含大约 500元素。
这是我当前情况的简短描述，我应该编写一个单元测试。 当然，由于最小输出大小约为 500 个元素，我无法真正将测试基于 assert 语句。所以这是我的问题：
测试这种方法的好主意是什么？
PS：我可以通过外部程序发送来手动验证输出；此类功能包含在我的 API 中，但使用这些类与单元测试的理念相冲突，不是吗？
编辑：API是用java开发的，我使用jUnit4进行测试。
Assume you have a method Tree supersizeMe(Tree input) . Both input and the return value are recursive data structures, and the method returns a structure with a size factor of about 500. Hence if input is the smallest element possible, the return value of the function contains about 500 elements.
This is the short description of a situation I currently have, and I am supposed to write a unit test.
Of course, having a minimal output size of ~500 elements, I can't really base my tests on assert-statements. So here is my question:
What is a good idea to test such a method?
PS: I can verify the output manually by sending it through an external program; Such functionality is included in my API, but using those classes conflicts with the idea of a unit-test, doesn't it?
Edit: The API is developed in java, and I use jUnit4 for tests.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
单元测试的想法是它单独测试单个代码单元。我不明白使用复杂的第三方代码来验证正确性会如何与之对抗。
真正的问题是，转换本身是否是一个足够简单的操作，失败的测试能让您很好地了解问题出在哪里。如果没有，您可能希望将其分解为可以独立测试的较小操作。
可能有 TDD 纯粹主义者声称任何不能立即完全理解并准确告诉您问题出在哪一行代码的测试都不是真正的单元测试，并且使用第三方 API 是不可接受的，但他们可以当你享受你的工作、经过测试的代码时，去接受他们的教条。
The idea of a unit test is that it tests single units of code in isolation. I don't see how using complex third-party code to verify correctness would run against that.
The real question is whether the transformation is in itself a simple enough operation that a failing test would give you a good idea where the problem is. If not, you may want to break it down into smaller operations that can be tested independently.
There may be TDD purists that claim any test that is not immediately and completely understandable and tells you exactly in which line of code the problem is is not a true unit test, and that using a third-party API is not acceptable, but they can go suck on their dogma while you enjoy your working, tested code.