* Design concept for Dispatcher
Part of: #11610
This change brings forward the Dispatcher as a more primary and more
expandable concept.
- Dispatcher shows up in more places
- Dispatcher is an abstract class for horizontal scalability
- Dispatcher has parallels with S.Windows.Threading.Dispatcher where
possible
Looking for feedback on this approach. I feel pretty strongly that
making this an abstract class is the right choice, I want to see
opinions on how much to push it into people's faces.
* WIP
* PR feedback
* Improved selenium start and tear down
* Selenium is set up and torn down in an assembly fixture.
* Selenium is initialized lazily and in a non-blocking way.
* Selenium processes are tracked as part of the build and their pids
written to a file on disk for cleanup in the event of unexpected
termination of the test process.
* Browser fixture retries with linear backoff to create a remote
driver. Under heavy load (like when we are doing a simultaneous NPM
restore) the selenium server can become unresponsive so we retry
three times, with a longer comand timeout allowance each time up to
a max of 3 minutes.
* Moved test project setup to build time instead of runtime.
* Added target PrepareForTest to create the required files for testing
* The template creation folder.
* The template props file to use our built packages.
* The folder for the custom hive.
* Added assembly metadata attributes to find all the data we need to
run the tests.
* Path to the artifacts shipping packages folder.
* Path to the artifacts non-shipping packages folder.
* Path to the test templates creation folder.
* Path to use for the custom templating hive used in tests.
* Proper cleanup as part of the build
* Remove the test templates creation folder.
* Remove the test packages restore path.
* Recreate the test templates creation folder.
* Recreate the test packages restore path.
* Generated Directory.Build.Props and Directory.Build.Targets in the
test templates creation folder.
* Cleaned up potentially stale templatetestsprops.
* Improved test flows
* Initialization is done lazily and asynchronously.
* Selenium
* Browser fixture
* Template initialization.
* Flattened test flows to avoid assertions inside deep callstacks.
* All assertions happen at the test level with improved error messages.
* With the exception of the migrations assertions.
* Assertions contain information about which step failed, for what
project and what failure details.
* Broke down tests to perform individual steps instead of mixing build
and publish.
* Publish project.
* Build project. (Debug)
* Run built project.
* Run published project.
* Concentrated build logic into the Project class.
* Context between the different steps of a test is maintained in
this class.
* All operations that require coordination are performed within this
class.
* There is a lock for dotnet and a lock for nodejs. When building
SPAs we acquire the nodejs lock to correctly prevent multiple
runs of nodejs in parallel.
[ApiAuthorization template cleanups]
* Fix preview3 issues with breaking changes on Entity framework by
manually configuring the model in ApiAuthorizationDbContext.
* Add app.db to the project file when using local db.
* Fix linting errors on angular template.
* Fix react tests
* Add tests to cover new auth options in the SPA templates.
* Unify the Templating and Components testing infrastructure.
* Enable test project discovery in the components E2E tests.
* Enable selectively disabling Selenium tests through build properties.
Ryan Nowak
Javier Calvarro Nelson
Pranav K
Nate McMaster