创建 nunit 测试而不使用 api 导出它们
我是使用 nunit 进行单元测试（以及一般的 Java 开发）的新手。 当为类上的私有方法创建单元测试时，测试文件似乎必须与被测试的类位于同一包中。 避免导出单元测试 API 的典型方法是什么？ 我可以对类/测试方法进行包保护吗？ 或者开发人员通常是否有一个单独的版本用于发布，不包括单元测试文件？
I'm new to unit testing using nunit (and Java development in general). When creating unit tests for private methods on classes, it looks as though the test file must be in the same package as the class being tested. What is the typical way of avoiding exporting the APIs of the unit tests? Can I make the classes/test methods package-protected? Or do developers typically have a separate build for release that excludes unit test files?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我认为将测试代码移出 CUT（被测类）包是错误的。 在某些时候，您可能想要测试受保护的方法或类，而将测试代码放在另一个包中会使这变得困难或不可能。
更好的解决方案是为测试代码创建一个单独的目录，该目录仅反映生产代码的包结构。 这就是我所做的：
然后，当需要打包和部署时，您的构建脚本可以非常简单地忽略
src/test/**。I think it's a mistake to move your test code out of the package of the CUT (Class Under Test). At some point you may want to test a protected method or class, and having your test code in another package makes that hard or impossible.
A better solution is to create a separate directory for your test code that simply mirrors the package structure of your production code. Here's what I do:
Then your build script can very simply ignore
src/test/**when it comes time for packaging and deployment.我可以告诉 IntelliJ 或 Ant 不要在部署中打包 JUnit 测试。 我在与源代码不同的目录中进行了测试，这使得它成为可能。
不要将源类和测试类混合在一起。 将它们分开，以便您使用的工具/脚本更容易部署。
I can tell IntelliJ or Ant not to package JUnit tests in the deployment. I have tests in a separate directory from the source code, which is what makes it possible.
Don't mingle source and test classes together. Keep them separate to make it easier for the tool/script you use to deploy.
测试文件不一定必须与被测试的类位于同一包中。 事实上，将测试文件放在完全独立的包中是一个很好的做法，这样他们就可以测试公共 API，而无需关心包级别的实现细节。
或者，您可以将构建脚本（例如 Nant）设置为在构建发布可执行文件时忽略包含“Test”的文件。
The test file does not necessarily have to be in the same package as the class being tested. In fact, it is a good practice to have the test files in a completely separate package, allowing them to test the public API without being concerned with package-level implementation details.
Alternately, you can set up your build script (e.g. Nant) to ignore files containing "Test" when you build your release executable.
就我个人而言，我的方法只是测试公开的功能，因此您最终只能测试封装良好的部分。
这通常导致我的设计包含具有明确功能的小类，这些类更容易测试。
一般来说，在进行单元测试时，您不应该关心所测试内容的内部结构，因此我发现这是实现它的最佳方法。
我也同意最好将测试代码和生产代码分开。
Personally my approach is only to test exposed functionality, so you end up testing well encapsulated parts only.
This usually leads my design to contain small classes with well defined functionality, which are easier to test.
Generally, when unit testing you shouldn't be concerned with the internals of what you're testing, so I find this is the best way to approach it.
I also agree it's best to seperate test and production code.
将测试源代码保留在应用程序源代码之外。 一般来说，仅测试公开的功能。 如果您确实需要测试私有行为，请创建一个扩展真实对象并允许公共访问私有行为的测试对象。
Keep test source code out of application source code. In general, only test exposed functionality. If you really need to test private behavior, create a test object that extends the real object and allows publec access to the private behavior.