About the Testing Approach - adamfoneil/CloudObjects GitHub Wiki

There are two test projects in the solution:

  • Testing.App tests the MVC endpoints and SQL queries within the backend application.
  • Testing.Client tests the CloudObjectsClient, the installable NuGet package.

Why Separate Projects?

They are separate projects because of how I implemented the model classes. A single test project would lead to duplicate model classes, which wouldn't compile. Here's a look at the error you get if you reference both the App and Client projects from the same project. Visual Studio will report that the model classes have duplicate definitions.

img

The reason for this is because of how I implemented server-side validation and trigger behavior. I use IValidate and ITrigger, which come from AO.Models, and are integral to my data access implementation. These interfaces have a database connection dependency. A database dependency is inappropriate for the Client NuGet package because it's a secret owned by the backend application. The API client never makes a direct database connection.

However, both the Client and App must share the same model classes to some degree. For example the Account and StoredObject classes appear both in the Client and App projects. Crucially though, I need to keep the IValidate and ITrigger implementations out of the Client project. I achieve the separation with partial classes such as Account_ext.cs, StoredObject_ext.cs, and AuditedTable_ext.cs. That separation lets me keep backend code at the model layer where I want it, but doesn't leak into the Client project.

[WIP]