Question

我正在开发一个项目，该项目为公司内的其他小组提供相关功能库...

最近很明显，其他组正在以不稳定的方式使用该库 - 所以我的任务是限制项目中的类的范围，以便只使用一个单例类作为项目的入口点

我做了什么 1）删除＆＃34; public＆＃34;来自＆＃34;内部＆＃34;的类修饰符类 2）将方法设置为＆＃34; protected＆＃34;

结果这个更新非常棒，因为现在无法在项目之外访问那些不打算暴露的类。

HOWEVER ，由于范围有限，测试用例现在无法构建。

编写测试用例的人以这样的方式编写代码，即单独实例化类并进行操作。由于范围有限（测试用例在另一个包中），这已不再可能。

问题要纠正这个问题，测试用例是否应该通过单例访问内部（私有）类，还是有另一种方式？

Answer 1

您的代码应以便于单元测试的方式编写。无法通过公共API访问的内部实施细节通常通过您的公共API进行测试。

另外，假设我们在这里谈论JUnits，按照惯例，你的测试应该在同一个包中，而不是一个不同的包。如果有，那么即使您的方法是默认/包可见性，同一个包中的测试仍然可以访问该代码。

你应该以一种易于测试的方式编写代码 - 如果你发现自己做的事情看起来太难了，那么你很可能会让自己变得困难。返回并再次查看代码，看看是否可以重构它以便于测试。

Answer 2

将您的测试放在同一个包中！如果你想让它们分开，只需将它们放在另一个目录中：

.
└── src
    ├── main
    │   └── com.my.package
    └── test
        └── com.my.package

Answer 3

有一种方法，但出于尽职调查，我必须回应别人所说的话，并说测试类应该在同一个包中。任何与此不同的方法都会很痛苦。您需要花费更长的时间来编写额外的代码来访问内部类数据，否则您将编写不可测试的代码。如果我没有意识到这一点，或者你已经说过，就没有好处。

您对图书馆所说的内容是用户可以轻松编写“不稳定”的代码。意味着你在API中犯了一些设计错误，没有什么可以为我们所做的事而感到羞耻。

此外，它还让我关注你谈论单一入口点和单身人士的方式。单例的最明显的用例是用于对文件执行操作。如果您有多个具有此prevallige的实例，您可以同时进行分配和写入。我不认为这种模式有助于控制人们如何使用您的图书馆。

对我来说很难说，听起来你有一些设计缺陷，并且你有一些特别的问题，你试图解决这些问题，这些问题实际上只是这些缺陷的症状，并且无法以任何简单的方式修复。