Creation of View should be a part of View or ViewModel [MVVM]?

Question

* Main purpose of adding the VM in MVVM *

Can we say :

1. ViewModel was introduced in MVVM for Unit test the Code.
   If we compare MVC and MVVM , MVC unit testing the Controller was difficult without View.
   So we have added one more layer ViewModel for unit testing the main code.

2. Manage some non persisted data that Model doesn't persists. ViewModel is introduce to manage some non persisted data and as per user input persist that data into database with Model .
   Validate data changes in Model and persist as per the Command.
   Manage Data Binding.

And also I have seen most MVVM samples for Command binding conatins ViewModel initializing another View on execute of some command. This directly states the view is dependent on ViewModel.

View --> ViewModel --> Model

ViewModel should be a independent testable unit.

Initializing code of view#2 from view#1 should be the part of view#1 code behind file.

Example :

If I want to call a MessageBox(view#2). Message box should be invoked in View#1 and based on message box results(Yes\\No) to perform operation, we should call appropriate method in ViewModel#1. With this ViewModel will be independent from view and we can write unit test easily.

Answer 1

"ViewModel was introduced in MVVM for Unit test the Code."

Not exactly. Properly decoupled code is easy to test. But that is a nice benefit of good design, not the reason. Code is decoupled and split into smaller units because the smaller units can be understood, while a single god object class consisting of 50'000 lines of code can not be fully understood.

We break code into independent parts with small and limited interfaces so that problems can be looked at in isolation, and changes to one class don't have a ripple effect through an entire system. As a side effect, the parts become simple enough to be fully tested by unit tests.

Forcing developers to write unit tests creates a greater incentive for developers to design classes right, by making the tests harder to write if the responsibilities of classes aren't chosen sensibly. But it's always better if developers already care about this, regardless of Unit Tests.

Back to the ViewModel. The Model is data. The ViewModel is data in a presentable format. For a simple throwaway program, they may be the same, but usually the data in the Model has some constraints such as having to be serializable, or being provided from somewhere else. The ViewModel changes the format of the data.

You may even have multiple ViewModels for a single Model, presenting the data in different ways for different Views. And multiple similar Views may share the same ViewModel, altough very often the relationship is 1:1.

You are correct that the ViewModel must not know the View and the Model must not know the ViewModel.