Formatting Updates and WIP

Updating functional testing with 2.1 approach

Author: ardalis

docs/standard/microservices-architecture/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-design.md

@@ -12,6 +12,7 @@ ms.workload:
   - "dotnet"
   - "dotnetcore"
 ---
+
 # Designing the infrastructure persistence layer
 
 Data persistence components provide access to the data hosted within the boundaries of a microservice (that is, a microservice’s database). They contain the actual implementation of components such as repositories and [Unit of Work](http://martinfowler.com/eaaCatalog/unitOfWork.html) classes, like custom EF DBContexts.
@@ -103,7 +104,7 @@ We find repositories useful, but we acknowledge that they are not critical for y
 
 The Specification pattern (its full name would be Query-specification pattern) is a Domain-Driven Design pattern designed as the place where you can put the definition of a query with optional sorting and paging logic.
 
-The Specification pattern defines a query in an object. For example, in order to encapsulate a paged query that searches for some products, you can create a PagedProduct specification that takes the necessary input parameters (pageNumber, pageSize, filter, etc.). Then, within any Repository method (usually a List() overload) it would accept an ISpecification and run the expected query based on that specification.
+The Specification pattern defines a query in an object. For example, in order to encapsulate a paged query that searches for some products, you can create a PagedProduct specification that takes the necessary input parameters (pageNumber, pageSize, filter, etc.). Then, within any Repository method (usually a List() overload) it would accept an `ISpecification` and run the expected query based on that specification.
 
 There are several benefits to this approach:
 
@@ -113,10 +114,10 @@ There are several benefits to this approach:
 
 * A specification can also be used to describe the shape of the data to be returned, so that queries can return just the data they required. This eliminates the need for lazy loading in web applications (which is usually not a good idea) and helps keep repository implementations from becoming cluttered with these details.
 
-An example of a generic Specification interface is the following code from [eShopOnWeb](https://github.com/dotnet-architecture/eShopOnWeb ).
+An example of a generic Specification interface is the following code from [eShopOnWeb](https://github.com/dotnet-architecture/eShopOnWeb).
 
 ```csharp
-// https://github.com/dotnet-architecture/eShopOnWeb 
+// https://github.com/dotnet-architecture/eShopOnWeb
 public interface ISpecification<T>
 {
     Expression<Func<T, bool>> Criteria { get; }
@@ -133,38 +134,37 @@ In the upcoming sections, it is explained how to implement the Specification pat
 
 ### The Repository pattern
 
--   **Edward Hieatt and Rob Mee. Repository pattern.**
-    [*http://martinfowler.com/eaaCatalog/repository.html*](http://martinfowler.com/eaaCatalog/repository.html)
+* **Edward Hieatt and Rob Mee. Repository pattern.**
+  [_http://martinfowler.com/eaaCatalog/repository.html_](http://martinfowler.com/eaaCatalog/repository.html)
 
--   **The Repository pattern**
-    [*https://msdn.microsoft.com/library/ff649690.aspx*](https://msdn.microsoft.com/library/ff649690.aspx)
+* **The Repository pattern**
+  [_https://msdn.microsoft.com/library/ff649690.aspx_](https://msdn.microsoft.com/library/ff649690.aspx)
 
--   **Repository Pattern: A data persistence abstraction**
-    [*http://deviq.com/repository-pattern/*](http://deviq.com/repository-pattern/)
+* **Repository Pattern: A data persistence abstraction**
+  [_http://deviq.com/repository-pattern/_](http://deviq.com/repository-pattern/)
 
--   **Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software.** (Book; includes a discussion of the Repository pattern)
-    [*https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/*](https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/)
+* **Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software.** (Book; includes a discussion of the Repository pattern)
+  [_https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/_](https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/)
 
 ### Unit of Work pattern
 
--   **Martin Fowler. Unit of Work pattern.**
-    [*http://martinfowler.com/eaaCatalog/unitOfWork.html*](http://martinfowler.com/eaaCatalog/unitOfWork.html)
+* **Martin Fowler. Unit of Work pattern.**
+  [_http://martinfowler.com/eaaCatalog/unitOfWork.html_](http://martinfowler.com/eaaCatalog/unitOfWork.html)
 
 <!-- -->
 
--   **Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application**
-    [*https://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application*](https://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application)
+* **Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application**
+  [_https://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application_](https://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application)
 
 ### The Specification pattern
 
--   **The Specification pattern.**
-    [*http://deviq.com/specification-pattern/*](http://deviq.com/specification-pattern/)
+* **The Specification pattern.**
+  [_http://deviq.com/specification-pattern/_](http://deviq.com/specification-pattern/)
 
--   **Evans, Eric (2004). Domain Driven Design. Addison-Wesley. p. 224.**
+* **Evans, Eric (2004). Domain Driven Design. Addison-Wesley. p. 224.**
 
--   **Specifications. Martin Fowler**
-    [*https://www.martinfowler.com/apsupp/spec.pdf/*](https://www.martinfowler.com/apsupp/spec.pdf)
+* **Specifications. Martin Fowler**
+  [_https://www.martinfowler.com/apsupp/spec.pdf/_](https://www.martinfowler.com/apsupp/spec.pdf)
 
->[!div class="step-by-step"]
-[Previous] (domain-events-design-implementation.md)
-[Next] (infrastructure-persistence-layer-implemenation-entity-framework-core.md)
+> [!div class="step-by-step"][previous] (domain-events-design-implementation.md)
+> [Next](infrastructure-persistence-layer-implemenation-entity-framework-core.md)

docs/standard/modern-web-apps-azure-architecture/test-asp-net-core-mvc-apps.md

@@ -10,10 +10,11 @@ ms.workload:
   - "dotnet"
   - "dotnetcore"
 ---
+
 # Test ASP.NET Core MVC Apps
 
-> _"If you don't like unit testing your product, most likely your customers won't like to test it, either."_
-> _- Anonymous-
+> *"If you don't like unit testing your product, most likely your customers won't like to test it, either."*
+ > \_- Anonymous-
 
 ## Summary
 
@@ -100,19 +101,19 @@ Figure 9-3 Add an xUnit Test Project in Visual Studio
 
 You should name your tests in a consistent fashion, with names that indicate what each test does. One approach I've had great success with is to name test classes according to the class and method they are testing. This results in many small test classes, but it makes it extremely clear what each test is responsible for. With the test class name set up to identify the class and method to be tested, the test method name can be used to specify the behavior being tested. This should include the expected behavior and any inputs or assumptions that should yield this behavior. Some example test names:
 
--   CatalogControllerGetImage.CallsImageServiceWithId
+* CatalogControllerGetImage.CallsImageServiceWithId
 
--   CatalogControllerGetImage.LogsWarningGivenImageMissingException
+* CatalogControllerGetImage.LogsWarningGivenImageMissingException
 
--   CatalogControllerGetImage.ReturnsFileResultWithBytesGivenSuccess
+* CatalogControllerGetImage.ReturnsFileResultWithBytesGivenSuccess
 
--   CatalogControllerGetImage.ReturnsNotFoundResultGivenImageMissingException
+* CatalogControllerGetImage.ReturnsNotFoundResultGivenImageMissingException
 
 A variation of this approach ends each test class name with "Should" and modifies the tense slightly:
 
--   CatalogControllerGetImage**Should**.**Call**ImageServiceWithId
+* CatalogControllerGetImage**Should**.**Call**ImageServiceWithId
 
--   CatalogControllerGetImage**Should**.**Log**WarningGivenImageMissingException
+* CatalogControllerGetImage**Should**.**Log**WarningGivenImageMissingException
 
 Some teams find the second naming approach clearer, though slightly more verbose. In any case, try to use a naming convention that provides insight into test behavior, so that when one or more tests fail, it's obvious from their names what cases have failed. Avoid naming you tests vaguely, such as ControllerTests.Test1, as these offer no value when you see them in test results.
 
@@ -167,19 +168,7 @@ The \_logger and \_imageService are both injected as dependencies. Now you can t
 
 ## Integration Testing ASP.NET Core Apps
 
-```cs
-    }
-        catch (FileNotFoundException ex)
-        {
-            throw new CatalogImageMissingException(ex);
-        }
-    }
-}
-```
-
-This service uses the IHostingEnvironment, just as the CatalogController code did before it was refactored into a separate service. Since this was the only code in the controller that used IHostingEnvironment, that dependency was removed from CatalogController's constructor.
-
-To test that this service works correctly, you need to create a known test image file and verify that the service returns it given a specific input. You should take care not to use mock objects on the behavior you actually want to test (in this case, reading from the file system). However, mock objects may still be useful to set up integration tests. In this case, you can mock IHostingEnvironment so that its ContentRootPath points to the folder you're going to use for your test image. The complete working integration test class is shown here:
+To test that a LocalFileImageService works correctly using an integraiton test, you need to create a known test image file and verify that the service returns it given a specific input. You should take care not to use mock objects on the behavior you actually want to test (in this case, reading from the file system). However, mock objects may still be useful to set up integration tests. In this case, you can mock IHostingEnvironment so that its ContentRootPath points to the folder you're going to use for your test image. The complete working integration test class is shown here:
 
 ```cs
 public class LocalFileImageServiceGetImageBytesById
@@ -188,6 +177,7 @@ public class LocalFileImageServiceGetImageBytesById
     private readonly Mock<IHostingEnvironment> _mockEnvironment = new Mock<IHostingEnvironment>();
     private int _testImageId = 123;
     private string _testFileName = "123.png";
+
     public LocalFileImageServiceGetImageBytesById()
     {
         // create folder if necessary
@@ -196,33 +186,36 @@ public class LocalFileImageServiceGetImageBytesById
         System.IO.File.WriteAllBytes(filePath, _testBytes);
         _mockEnvironment.SetupGet<string>(m => m.ContentRootPath).Returns(GetFileDirectory());
     }
+
     private string GetFilePath(string fileName)
     {
         return Path.Combine(GetFileDirectory(), "Pics", fileName);
         }
             private string GetFileDirectory()
         {
-            var location = System.Reflection.Assembly.GetEntryAssembly().Location;
-            return Path.GetDirectoryName(location);
-        }
+        var location = System.Reflection.Assembly.GetEntryAssembly().Location;
+        return Path.GetDirectoryName(location);
+    }
 
-        [Fact]
-        public void ReturnsFileContentResultGivenValidId()
-        {
-            var fileService = new LocalFileImageService(_mockEnvironment.Object);
-            var result = fileService.GetImageBytesById(_testImageId);
-            Assert.Equal(_testBytes, result);
-        }
+    [Fact]
+    public void ReturnsFileContentResultGivenValidId()
+    {
+        var fileService = new LocalFileImageService(_mockEnvironment.Object);
+        var result = fileService.GetImageBytesById(_testImageId);
+        Assert.Equal(_testBytes, result);
     }
+}
 ```
 
 > [!NOTE]
-> that the test itself is very simple – the bulk of the code is necessary to configure the system and create the testing infrastructure (in this case, an actual file to be read from disk). This is typical for integration tests, which often require more complex setup work than unit tests.
+> The test itself is very simple – the bulk of the code is necessary to configure the system and create the testing infrastructure (in this case, an actual file to be read from disk). This is typical for integration tests, which often require more complex setup work than unit tests.
 
 ## Functional Testing ASP.NET Core Apps
 
 For ASP.NET Core applications, the TestServer class makes functional tests fairly easy to write. You configure a TestServer using a WebHostBuilder, just as you normally do for your application. This WebHostBuilder should be configured just like your application's real host, but you can modify any aspects of it that make testing easier. Most of the time, you'll reuse the same TestServer for many test cases, so you can encapsulate it in a reusable method (perhaps in a base class):
 
+WIP: Update for 2.1
+
 ```cs
 public abstract class BaseWebTest
 {
@@ -233,7 +226,7 @@ public abstract class BaseWebTest
     {
         _client = GetClient();
     }
-    
+
     protected HttpClient GetClient()
     {
         var startupAssembly = typeof(Startup).GetTypeInfo().Assembly;
@@ -274,6 +267,5 @@ public class CatalogControllerGetImage : BaseWebTest
 
 This functional test exercises the full ASP.NET Core MVC application stack, including all middleware, filters, binders, etc. that may be in place. It verifies that a given route ("/catalog/pic/1") returns the expected byte array for a file in a known location. It does so without setting up a real web server, and so avoids much of the brittleness that using a real web server for testing can experience (for example, problems with firewall settings). Functional tests that run against TestServer are usually slower than integration and unit tests, but are much faster than tests that would run over the network to a test web server.
 
->[!div class="step-by-step"]
-[Previous] (work-with-data-in-asp-net-core-apps.md)
-[Next] (development-process-for-azure.md)
+> [!div class="step-by-step"][previous] (work-with-data-in-asp-net-core-apps.md)
+> [Next](development-process-for-azure.md)