A unit test is a runnable piece of code that verifies that another piece of code (called production code) does what it is supposed to do.
A unit test has many characteristics and one of the most important is that a single unit test must verify one and only one thing.
If a unit test specifies more than one behavior things became harder to mantain. One a tests fail it has to be easy to understand what is going wrong and which section of our production code is behaving badly.
As a best practice we make each test independent to all the others: any given behaviour should be specified in one and only one test. Otherwise if you later change that behaviour, you’ll have to change multiple tests.
I’m sure we all hear about unit testing, test driven development and so on. These practices are useful and provide a long list of benefit like writing low-coupled and mantainable code to name a few.
We want to write unit test for our UWP Prism application and we’d like, for example, to put our ViewModels under tests to make sure the logic they implement is correct. Unit testing is possible only if we can get rid of all the dependencies in our class under test because we want to run our test every time we want (for exemple when the service library our teammate is writing is not yet finished) and as fast as we can.