I generally like to keep my Service Layer entities as clean as possible, so they usually end up being POCOs (Plain Old CLR Objects), classes that only contain property definitions without any methods.

After working for a while at a job that necessitates writing unit tests, the benefits of unit test coverage has become undeniably clear.

With that said, I can admit that for new and very tiny personal projects, the benefits arent as profound.

You most likely will have the small codebase and product understood well enough, such that when you make a change youll also be conscious of other places that are affected.

Start writing them early on in the beginning of a new project, and try to keep your tests in parity as you add new features or change code.

Its a lot easier writing tests as you go, as opposed to writing a huge application without them and having to painstakingly write them all at once.

Also, most companies out there require unit testing (among other kinds of tests) so you might as well start getting into a habit that has great practical value.

Its not going to cover every aspect of unit testing or get into advanced edge cases, but it will be thorough enough to provide a foundation for you to start implementing tests in your projects.

I personally use Visual Studio 2015, and the projects contained in the solution are.NET Core 1.1 projects.

Towards the end of the tutorial, Ive setup some empty practice tests that you can fill in using what youll learn as practice.

Well dive into it in more depth later, but an assertion is essentially a statement that you want to test.

An example, in English, would be The expected result of running this method is false.

If the method you created should produce a false return value but it returns true when running the test, you can conclude that either something in your testing logic or the actual code youre testing is flawed.

Ive split the solutions src codebase into three separate projects as depicted below.

It also contains the SQL entities that are returned from the DatabaseContext making calls to our pretend database layer.

CoreAbstractions contains our primary Entities that are used within the service layer.

Its good practice to separate your models for an Entity by layers.

Your web model might only need a subset of the model retrieved from the database, or maybe even some completely different bits of information.

So rather than keeping one monolithic model that contains the properties needed for every aspect or layer of your application, you create a separate model for each layer.

For example, in the service layer, if more than one service needs to reference a Person, they would all use and pass around a Person type object.

However, once you need to jump layers, the model changes so you need to map one to another.

Similarly, if there was a UserModel class thats used in the Web Layer, Id add a mapping method there as well, that takes a Service Layer model and maps it to the Web model.

Moq Get Moc