Unit tests and UI/system tests are very different things with very different purposes.
Unit tests should test the proper behavior of your application at the unit level (e.g. this method, given inputs x and y, should return the value z), and you will likely have lots of them (hundreds, if not thousands or tens of thousands in a large project).
Unit tests should be written to be small, fast, and to test each thing in isolation from external dependencies such as databases, web services, the file system, the current date/time, etc. They should ideally be written in such a way that the only possible reason for them to fail is because the code that they are testing has changed in some way that has broken the expected behavior.
Good tests should be run frequently, ideally every time the developer builds the code locally, then again during the CI process after the code is committed. A big suite of UI tests simply will not allow you to do that. The reason you want to run your tests frequently is because a bug that you find now is easier to fix than a bug you find later: Developers are juggling a ton of contextual information when they’re writing code. If they press the “build” button and a test pops up as failing a few seconds later, they haven’t lost that context and can easily fix the bug.
If they find out 3 hours later that the code they wrote 3 hours ago has a bug, by then they’ve probably moved on to a different task and lost a lot of that context. It takes time to get all of that context back, meaning it’s going to take longer to fix the bug. Plus, they likely have to put aside whatever new task they’re working on, causing them to lose context on that task, too, which they’ll have to pick back up on after they fix the bug.
The core idea here is that your unit tests should be repeatable and consistent. A test that you can’t trust is a test that you ignore, and a test that you ignore is utterly useless.
Coded UI (and all other sorts of tests that interact with the UI) are almost the exact opposite of unit tests in every way: They are very slow (tens of seconds instead of milliseconds), they depend on the entire system as a whole being correctly configured and deployed, and they are extremely brittle and prone to random failure. They generally should be used only as smoke tests, to ensure that an application has been properly deployed, and thus validate a few critical paths through the application.
If you try to validate business logic and correct application behavior via the UI, you are setting yourself up for a miserable experience. The tests will be too slow to run frequently, and changes to your application will require constant babysitting and fixing of UI tests that have broken as a result of the changes.
2
solved Unit tests with view models or coded ui test