两者的不同目的是什么?我的意思是,在什么情况下我应该做每一个?
至于示例条件。如果你有后端服务器和几个前端网站,你会做哪一个?先对后端服务器进行单元测试还是先在 Web UI 中进行 UI 测试?鉴于条件,服务器和前端 Web 已经存在,因此它不是与(TDD)一起构建的迭代设计......
两者的不同目的是什么?我的意思是,在什么情况下我应该做每一个?
至于示例条件。如果你有后端服务器和几个前端网站,你会做哪一个?先对后端服务器进行单元测试还是先在 Web UI 中进行 UI 测试?鉴于条件,服务器和前端 Web 已经存在,因此它不是与(TDD)一起构建的迭代设计......
单元测试旨在与世界其他地方隔离测试一小部分代码(单个类/方法)。
UI 测试可能是系统/功能/验收测试的不同名称,您可以在其中一起测试整个系统,以确保它在现实生活中完成它应该做的事情。(除非通过 UI 测试,您的意思是可用性/外观和感觉等测试,这通常受限于 UI 上的细节。)
在大多数项目中你都需要这两个,但在不同的时间:开发期间的单元测试(最好是从一开始,TDD风格),以及稍后的 UI 测试,一旦你实际上有一些完整的端到端功能要测试.
如果您已经让系统运行,但没有测试,那么实际上您有遗留代码。首先努力以最少的努力获得最好的测试覆盖率,这意味着高级功能测试。添加单元测试也是需要的,但它需要更多的努力,并且会在以后开始回报。
推荐阅读:有效地使用遗留代码。
应始终进行单元测试。单元测试可以证明您的技术解决方案的每个单元(阅读:对象)都能提供预期的结果。说得非常(也许太)简单,用户测试是为了验证您的系统是否满足用户的需求。
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
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.