"Unit Testing" and build/eng files in project structure

[leusbj]

@CZEMacLeod ,

I was thinking about some custom targets which originally helped to quckly illustrate which files were getting collected into the well-known ItemGroups by various globbing patterns, but perhaps might be altered to act like a "Unit Test"... helping to validate that the SDK performs Item Selection as expected under specific scenarios.

Would you have any interest in hearing/seeing something more on that?

As I was thinking about that idea, I was also looking at the existing Directoty.Build.props and Directory.Build.targets and some of the properties established/set within those files. I think restructure/relocate some of these property setters might be beneficial if/when we pursue adding "Unit Tests".

A slight restructure of these might look like:

- RepoRoot
  * Directory.Build.props
            -> leave things that apply to all samples/nuget-pack/template projects
  * Directory.Build.targets
            -> leave things that apply to all samples/nuget-pack/template projects
  - src
     * Directory.Build.props
            -> Import higher up Directory.Build.props if exists
            -> move setting EnableDefaultNoneItems to false here so it only effects the "nugetpackage projects"
            -> move setting NoWarn to specific warning values here so it only effects the "nugetpackage projects"
     * Directory.Build.targets
            -> Import higher up Directory.Build.targets if exists
            -> move setting ReadMe/Sufficient inclusion here so it only effects the "nugetpackage projects"
            -> move setting PackageProperties (Copyright, Auther, etc) to specific warning values here so it only effects the "nugetpackage projects"
     - MSBuild.SDK.SystemWeb
     - MSBuild.SDK.SystemWeb.Razor
  - tests
     * Directory.Build.props
            -> Import higher up Directory.Build.props if exists
            -> configure properties/behavior that only apply to "test projects"
     * Directory.Build.targets
            -> Import higher up Directory.Build.targets if exists
            -> configure properties/behavior that only apply to "test projects"
     - MSBuild.SDK.SystemWeb.Tests
        - MSBuild.SDK.SystemWeb.AspNet2_0Folders.Tests
        - MSBuild.SDK.SystemWeb.WebForms.Tests
        - Etc

[CZEMacLeod]

@leusbj I don't really have an issue with either idea. I'm all for Unit Tests, although I'm not quite sure how you would implement those specifically in this case.
Right now, I pack the SDK and use the preview version locally with the samples, which I then run and make sure they spin up and work as expected. It might be possible to automate that in some way to do tests as part of the release process, but I'm a little unsure of how that would look exactly.

I'd be happy to have more tests and/or samples added to the repo, or more documentation on the existing stuff.

I mainly put this together originally from the thread mentioned in the readme, along with some stuff I had already done in my local projects (I think much like yourself) - but wanted to 'give back' so made the SDK available here.

I'd also like to make the templates better - add more options, like the framework version and set the appropriate SDK property and web.config stuff. Allow turning on/off MVC, WebAPI etc. like the 'original' templates, and so on.
I was also considering adding an XMLPoke target to ensure the web.config target runtime matched the SDK property, if you changed it down the line.
A similar idea is to inject the assembly name/version in Views/web.config for System.Web.Mvc based on the MicrosoftAspNetMvc_Version property, or some mechanism around the resolved assembly.

Your structure looks fine for the most part - you did miss out MSBuild.SDK.SystemWeb.Templates from the src directory, and I'm not sure if you plan on putting the existing samples into the tests directory, or have a separate samples folder.

I'd like to keep the properties etc. at as high a level as possible in the Directory.Build.* files, to ensure consistency, and to ensure that they cover everything needed. If there is an issue, perhaps don't inherit them in the tests folder, or make sure things are overridden. I think the changes to EnableDefaultNoneItems and NoWarn are definitely correct though. You will probably also need a copy of the nuget.config from the samples folder in the tests folder too.

The title of the discussion mentions build/eng... but you haven't said anything about that (that I can see). Could you elaborate on what you wanted to do there?

I would suggest maybe breaking it down into separate PRs, so we can review each change more easily, and we can see the changes at each step, in case we have to revert something.

[leusbj]

Sorry for being unclear. I've seen various myRepo.SomeBehavior.props and anotherBehavior.targets located in a build or eng directory near the root of the repo, and then included/referenced from Directory.Build.* at different levels to bring in the behaviors as desired to different types of projects in the repo.

Your confirmation that this has "grown" from things you found useful (starting with the SDK nuget package... adding multiple packages, VS2022 CLI Templates, etc) matches what I was thinking in terms of these "build" or "eng" organizations.

I wanted to see if proposing some additions/alterations that only help those working on the SDK project, and not directly providing capabilities to consumers of the SDK was a worthwhile pursuit.

I'll put it together as 2 different PRs... First one that focuses on the structure changes, and a after that will look at the "Unit Test" concepts.

As an insight to where my thoughts where running for unit tests is potentially like

Validating ProjectItem selection
Given a specific Project Defnition (csproj) and a specific list of files on disk under the project directory
AND we have prediction (Expected) which files will be "None", "Content", "Compile","EmbeddedResource" stored as part of repo
AND a custom target that runs sometime at/before the Compile step to "output" a listing of these well-known ItemGroups
AND another custom target that runs towards the end of the build process that compares the Actual project items to the Expected project items (this could be similar to the "Compare Hash" mechanism as used in the previous BindingRedirects approach) emitting an "error" whenever the hashes don't match
WHEN The project is "built" then the pair of these targets will indicate with success/failure on if expectations matched actual