UI 测试与单元测试
这两者的不同目的是什么？我的意思是，在什么情况下我应该做每一个？
至于示例条件。如果您有后端服务器和多个前端 Web，您会选择哪一个？首先对后端服务器进行单元测试，还是先在 Web UI 中进行 UI 测试？ 在这种情况下，服务器和前端网络已经存在，所以它不是一个迭代设计来构建（TDD）......
what is the different purpose of those both? I mean, in which condition I should do each of them?
as for the example condition. if you have the backend server and several front-end webs, which one you'll do?do-unit testing the backend server first or do-UI testing in the web UI first?
given the condition, the server and the front-end webs already exist, so it's not an iterative design to build along with (TDD)...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
单元测试旨在与世界其他部分隔离地测试一小部分代码（单个类/方法）。
UI 测试可能是系统/功能/验收测试的不同名称，您可以一起测试整个系统，以确保它在现实生活环境下发挥应有的作用。 （除非 UI 测试指的是可用性/外观和感觉等测试，这通常仅限于 UI 上的细节。）
在大多数项目中，您都需要这两种测试，但在不同的时间：开发期间的单元测试（最好是从一开始，TDD 风格），以及稍后的 UI 测试，一旦你实际上有了一些完整的端到端功能进行测试。
如果您的系统已经在运行，但没有进行测试，那么实际上您拥有的是遗留代码。首先力争以最少的努力获得最佳的测试覆盖率，这意味着高水平的功能测试。添加单元测试也是需要的，但需要付出更多的努力，并且稍后才开始得到回报。
推荐阅读：有效使用旧代码。
Unit testing aims to test small portions of your code (individual classes / methods) in isolation from the rest of the world.
UI testing may be a different name for system / functional / acceptance testing, where you test the whole system together to ensure it does what it is supposed to do under real life circumstances. (Unless by UI testing you mean usability / look & feel etc. testing, which is typically constrained to details on the UI.)
You need both of these in most of projects, but at different times: unit testing during development (ideally from the very beginning, TDD style), and UI testing somewhat later, once you actually have some complete end-to-end functionality to test.
If you already have the system running, but no tests, practically you have legacy code. Strive to get the best test coverage achievable with the least effort first, which means high level functional tests. Adding unit tests is needed too, but it takes much more effort and starts to pay back later.
Recommended reading: Working Effectively with Legacy Code.
应该始终进行单元测试。单元测试可以提供证据，证明您的技术解决方案的每个单元（读作：对象）都能提供预期的结果。简而言之，用户测试是为了验证您的系统是否满足用户的需求。
Unit test should always be done. Unittests are there to provide proof that each UNIT (read: object) of your technical solution delivers the expected results. To put it very (maybe too) simple, user testing is there to verify that your system fulfills the needs and demands of the user.
测试金字塔 [1] 是这里的重要概念，Martin Fawler 对此进行了很好的描述。
简而言之，通过 UI 端到端运行的测试是：脆弱且编写成本昂贵。您可以考虑测试录制工具 [2] 来加速录制和重新录制。免责声明 - 我是此类工具的开发人员。
[1] https://martinfowler.com/articles/practical-test-pyramid.html
[2] https://anwendo.com
Test pyramid [1] is important concept here, well described by Martin Fawler.
In short, tests that run end-to-end through the UI are: brittle and expensive to write. You may consider test recording tools [2] to speed recording and re-recording up. Disclaimer - I'm developer of such tool.
[1] https://martinfowler.com/articles/practical-test-pyramid.html
[2] https://anwendo.com
除了已接受的答案之外，今天我刚刚提出了这个问题：为什么不以编程方式触发布局函数，然后也围绕它对逻辑进行单元测试？
我从一位高级开发人员那里得到的答案是：以编程方式触发布局函数不会是真实用户体验的绝对副本。在现实世界中，系统会触发许多回调，例如当应用程序的用户将应用程序置于后台或前台时。显然，您可以手动触发此类事件并再次测试，但是您确定所有序列中的所有事件都是正确的吗？！
真正的用户体验是用户进行实际的网络调用、点击屏幕、加载多个屏幕，有时您可能会收到系统回调。您忘记模拟而没有正确模拟的回调。在单元测试中，您主要是进行隔离测试。在 UI 测试中，您设置应用程序，可能需要登录等。您构建的堆栈比单元测试要复杂得多。因此，最好不要将单元测试与 UI 测试混合在一起。
In addition to the accepted answer, today I just came up with this question of why not just programmatically trigger layout functions and then unit-test your logic around that as well?
The answer I got from a senior dev was: programmatically trigger layout functions will not be an absolute copy of the real user-experience. In the real world, the system will trigger many callbacks, like when the user of an app backgrounds or foregrounds the app. Obviously you can trigger such events manually and test again, but would you be sure you got all events in all sequences right?!
The real user-experience is one where user makes actual network calls, taps on screens, loads multiple screen on top of each other and at times you might get system callbacks. Callbacks which you forgot to mock that you didn't properly mock. In unit-tests you're mainly testing in isolation. In UI test, you setup the app, may have to login, etc. That stack you build is much more complex vs a unit-test. Hence it's better to not mix unit-testing with UI testing.