Updating documentation around test projects. (#76)

The README documentation around test projects is out of date because there are currently 3 test projects instead of the one mentioned in the README. Rewording to reflect that reality.

README.md

@@ -68,9 +68,9 @@ The Infrastructure project depends on `Microsoft.EntityFrameworkCore.SqlServer`
 
 The entry point of the application is the ASP.NET Core web project. This is actually a console application, with a `public static void Main` method in `Program.cs`. It currently uses the default MVC organization (Controllers and Views folders) as well as most of the default ASP.NET Core project template code. This includes its configuration system, which uses the default `appsettings.json` file plus environment variables, and is configured in `Startup.cs`. The one dependency that you'll see used in this project is `StructureMap`, which is configured in the `Startup.cs` class. There are two reasons I prefer `StructureMap` to the built-in container that ships with ASP.NET Core (and which Microsoft states is only a starting point with minimal functionality). First, the above-mentioned technique for avoiding the need for project references between Web and Infrastructure projects. Second, its `WithDefaultConventions` convention saves a lot of boilerplate coding when you are wiring up implementations to interfaces that follow a simple naming convention. If for instance I have an `INotificationService` interface that I want to be resolved using an instance of `NotificationService`, in ASP.NET Core I would need to add a line of code to add this. With StructureMap's `WithDefaultConventions` convention, this wireup happens automatically. Any interface named `IWhatever` will be resolved by a class named `Whatever`.
 
-## The Test Project
+## The Test Projects
 
-In a real application I will likely have separate test projects, organized based on the kind of test (unit, functional, integration, performance, etc.) or by the project they are testing (Core, Infrastructure, Web), or both. For this simple starter kit, there is just one test project, with folders representing the projects being tested. In terms of dependencies, there are three worth noting:
+Test projects could be organized based on the kind of test (unit, functional, integration, performance, etc.) or by the project they are testing (Core, Infrastructure, Web), or both. For this simple starter kit, the test projects are organized based on the kind of test, with unit, functional and integration test projects existing in this solution. In terms of dependencies, there are three worth noting:
 
 - [xunit](https://www.nuget.org/packages/xunit) I'm using xunit because that's what ASP.NET Core uses internally to test the product. It works great and as new versions of ASP.NET Core ship, I'm confident it will continue to work well with it.