We have two options for running Unit Tests. Both have advantages and disadvantages.
Running Unit Tests Against your local development BoxA test would be written as shown below
This will produce a result such as
To have the test work we MUST configure IIS to provide the appropriate site, for example on 666
- Physical Path is pointing to the image you wish to test
- IIS port and path are matching
- IIS Server is running
Running Unit Tests Against a Development ServerNote: You need to STOP the above server for the following to work.
Our test is now written as:
The AspNetDevelopmentServerHost must be pointing at the source folder you wish to test.
We must now change the Web Application project to be found and available:
Again the test will run (with ability to debug into the web application if needed)
Gotcha of this approachThe Web.Config is rewritten at the start and at the end of running unit tests. Occasionally you will get error messages about web.config being locked by another process.
Recommended ApproachThe following template is recommended:
// [AspNetDevelopmentServerHost("C:\\GitHub\\develop\\AdminConsole", "/")]
This has the following advantages:
- If you have multiple branches, then by just changing the IIS settings to point at each branch, you can run the tests against each branch without touching the files.
- If there is a team working on the project, then there is no dependency on the physical location of the files (a big plus!)
- If there is a problem that needs investigation,
- Turn off IIS
- Uncomment the AspNetDevelopmentServerHost line and adjust the path (if needed)