Unit testing 单元测试与框架

我最近和我的主管就单元测试发生了一场争论。我的办公室目前正在为即将发布的版本开发DRs，他已经创建了一个DR流程。其中一个步骤是为您的博士开发一个单元测试。这就是我们意见分歧的地方。他告诉我，这个测试是通过用户界面执行的，功能测试和单元测试的区别在于单元测试更本地化。我认为单元测试必须是基于代码的，因为它应该只测试代码的单个部分，而这是隔离它的唯一方法。我还说过，对于开发的每个部分，例如开发或维护，单元测试几乎都是在框架（比如jUnit）中完成的。我想让一些人参与进来。可以通过应用程序的用户界面进行单元测试吗？实现单元测试最常用的方法是什么

---

*注：是的，我用谷歌搜索了一下，但我发现的大部分内容都很模糊，足以容纳我们两个相互矛盾的观点。我正在寻找更多真实世界的答案。谢谢你抽出时间。他错了。单元测试是单元测试，因为它隔离依赖项并测试代码的单个方面。通过用户界面运行的测试不是单元测试，因为即使显示UI也会涉及数十个依赖交互，在测试期间，您都无法隔离或控制这些交互

---

测试框架是不相关的。您可以使用“单元测试”框架，但仍然编写一些非单元测试的内容。例如，您编写了一个将文件写入文件系统的测试，并断言该文件存在。嗯，您的文件系统是一个您没有隔离的依赖项。您编写了一个集成测试，而不是单元测试。

单元测试并不一定意味着它是自动化的（即“基于代码的”）。注意：这是一个语义参数，它大部分是没有意义的。@EkoostikMartin:它不是没有意义的。您可以使用不同的计划运行不同类型的测试。因此，选择正确的类别是一个严肃的决定。PS：单元测试应该是自动化的。无法想象手动单元测试。@zerkms-老板希望通过用户界面进行测试，事实上他称之为单元测试（实际上不是），这是一个语义参数，因此毫无意义。如果证明他错误地命名了他想要的测试类型，那将一事无成。我几乎不会把一个涉及FS IO的测试称为集成测试。它是。您的文件系统表示一个外部依赖项。就这一点而言，当前日期也是如此。我从未听说过任何适合它的集成测试定义：