Blogs by Ashwin

  Continuous Delivery Options When launching anything into production, it's essential to eliminate any uncertain elements. This is where Continuous Integration and Continuous Delivery/Deployment (CI/CD) become relevant. GitHub Actions and Azure DevOps (or Azure Pipelines) are two Microsoft options for implementing CI/CD. There are numerous other alternatives, such as Jenkins, TeamCity, and GitLab - the options are extensive. If our current CI/CD solution is compatible with deploying ASP.NET, it will also be capable of managing Blazor since Blazor essentially functions as an ASP.NET application. We should ensure that we establish tests as a component of our CI/CD pipeline. The great aspect is that there is no requirement for additional hardware to test our components, it will function as long as our CI/CD pipeline can execute unit tests (nUnit, xUnit). We can execute all builds and tests whenever a pull request is made. If both the build and tests are successful, a team member condu...

  Mocking The API We can implement the mock API in two ways. One option is to set up an in-memory database, but to maintain simplicity, we'll opt for the alternative and create posts on demand: Under MyBlog.Shared.Tests , right-click on the Dependencies node and select Add Project References. Check MyBlog.Shared and click Ok. Now our test project has access to all the classes in our shared project as well as all the classes the shared project is referring to, such as Interfaces in the MyBlog.Data.Shared project. Select the MyBlog.Shared.Tests project. Press Shift + F2 to create a new file and name the file MyBlogApiMock.cs . Add the following namespaces- using MyBlog.Data.Interfaces; using MyBlog.Data.Models; Implement the IMyBlogApi interface. For BlogPost , add code in the class. When we get a blog post, we simply create one and fill it with predefined information that we can later use in our tests. The same thing goes for getting a list of blog posts. The same thing goes ...

  Introduction Conducting tests will enhance the product's quality since it ensures that previously functioning features continue to operate correctly. However, writing tests for UI components can often be challenging; the most prevalent approach is to launch the site and utilize tools that simulate button clicks, then analyse the results to confirm whether everything works as expected. The benefit of this approach is that it allows us to test our site across various browsers and devices. The drawback is that this testing process can be quite time-consuming. We have to launch the web application, open a web browser, confirm the outcomes of the test, close the web browser, and then repeat this for each subsequent test. We can apply this approach in Blazor in the same way as with any ASP.NET application, but Blazor offers additional options for testing. Steve Sanderson initiated a testing framework for Blazor, which was further developed by Microsoft MVP Egil Hansen. The framework cr...