例如，给定一个gui应用程序（如文字处理程序），公共api本身就是gui吗？然后测试公共api是否意味着编写测试以启动应用程序并操纵鼠标和键盘来按下按钮？我假设您不会像实际用户那样解析gui显示本身来测试预期结果。
库的公共api似乎更简单。我假设是将库导入另一个项目时可以访问的函数和类。
用功能范例编写的库又如何呢？程序？面向对象？没有明确的公共和私人划分的语言呢？
从本质上讲：“公共api”一词可以用一种语言，范例和与应用程序无关的方式来描述，并且用最少的术语吗？示例可能会有所帮助。
答案 0 :(得分：0)
“给定gui应用程序，如文字处理程序，公共api是gui本身吗？” 。不，您遇到的问题是您正在查看“全局”，而没有考虑单元测试的范围。
StackOverflow标记将其定义为：“ 单元测试是一种测试源代码的各个单元以确定它们是否适合使用的方法” 。从这个角度来看，该表达式很有意义，因为您正在测试每个单独的类。如果关注点分离良好，那么大多数此类甚至都不会意识到它们是“文字处理器”的一部分。
这个想法是，您应该仅根据其他类如何查看该类来测试该类，而不必考虑该类的私有实现。
例如，在测试包含事物集合的类时，测试不应基于以下事实：该集合是作为数组（或其他任何形式）私有持有的，并且“如果我将一个项目添加到集合中，则私有数组字段应包含我添加的项目”。即使内部类可能正常工作，如果更改内部实现，以这种方式编写的测试也会中断。
相反，测试应基于“如果我将一个项目添加到集合中，那么（例如）我应该能够通过枚举集合来取回它”，因为枚举可能在公共API中进行该类的。如果更改了内部实现，而无需更改类的行为，则这样编写的测试仍将起作用。
请注意，在考虑短语“公共API”部分时，范围很重要。考虑使用库时，您可能会认为这意味着您应该只测试公开公开的类。从查看每个单独类的范围来看（其中某些类可能无法从库外部访问），但每个类都公开了一个公共API，用于说明其他类应如何与它们交互。第二个范围是与单元测试有关的范围。并不是说第一个范围是不好的，只是测试整个库不是 unit 测试，而是 integration 测试。