DEV Community: Mark Taylor

Building a Software Survey using Blazor - Part 12 - Putting it all together

Mark Taylor — Mon, 21 Dec 2020 15:35:32 +0000

I've decided to write a small survey site using Blazor. Part of this is an excuse to learn Blazor.

As I learn with Blazor I will blog about it as a series of articles.

This series of articles is not intended to be a training course for Blazor - rather my thought process as I go through learning to use the product.

All articles in this series:

Part 1 - State
Part 2 - Better State
Part 3 - Components
Part 4 - Render Mode
Part 5 - Client IP
Part 6 - Azure Cosmos DB
Part 7 - Azure SignalR Service
Part 8 - bUnit
Part 9 - End to End Tests
Part 10 - Bicep
Part 11 - Azure DevOps
Part 12 - Putting it all together - this article

In this article I wanted to recap the previous articles in the series and how they fit together to produce the final Software Survey application.

Starting the survey

A number of things occur simply by the user visiting https://software-survey.red-folder.com/

Firstly, the static HTML is provided by the application.
The PreRenderLoadingMessage component I described in part 4 allows me to provide a loading page while the Blazor Server app starts up:

During the Server app start up, it will:

Get the IP address of the user - as discussed in part 5
Create the users state - as discussed in part 2
Sets up the SignalR connection - as discussed in part 7

The app is then ready to use and the PreRenderLoadingMessage will swap over from the loading page to the starting page.

The survey pages

As the user works through the survey, each page will use Dependency Injection to get the relevant part of the state.

Demographics page:

State defined as:

namespace SoftwareSurvey.Models
{
    public class Demographic
    {
        [Required(ErrorMessage = "Please provide company size")]
        [DisplayName("Company Size")]
        [JsonProperty(PropertyName = "companySize")]
        public string CompanySize { get; set; }

        [Required(ErrorMessage = "Please provide your job seniority")]
        [DisplayName("Job Seniority")]
        [JsonProperty(PropertyName = "jobSeniority")]
        public string JobSeniority { get; set; }

        [DisplayName("Job Title (optional)")]
        [JsonProperty(PropertyName = "jobTitle")]
        public string JobTitle { get; set; }

        [Required(ErrorMessage = "Please provide if your business is UK Based")]
        [DisplayName("Is your business UK based?")]
        [JsonProperty(PropertyName = "ukBased")]
        public string UKBased { get; set; }
    }
}

Injected as:

    [Inject]
    private Models.Demographic Model { get; set; }

Software Types page:

State defined as:

namespace SoftwareSurvey.Models
{
    public class SoftwareTypes
    {
        [DisplayName("eCommerce")]
        [Description("Website(s) selling products or services")]
        [Required(ErrorMessage = "Please select a value")]
        [JsonProperty(PropertyName = "eCommerce")]
        public int? ECommerce { get; set; }

        [DisplayName("Information Website")]
        [Description("Website(s) providing information (portfolio, blog, etc)")]
        [Required(ErrorMessage = "Please select a value")]
        [JsonProperty(PropertyName = "informationWebsite")]
        public int? InformationWebsite { get; set; }

        [DisplayName("Mobile App")]
        [Description("Application(s) for install on mobile or tablet")]
        [Required(ErrorMessage = "Please select a value")]
        [JsonProperty(PropertyName = "mobileApps")]
        public int? MobileApps { get; set; }

        [DisplayName("Line Of Business")]
        [Description("Application(s) to support specific business process")]
        [Required(ErrorMessage = "Please select a value")]
        [JsonProperty(PropertyName = "lineOfBusiness")]
        public int? LineOfBusiness { get; set; }

        [DisplayName("SaaS")]
        [Description("Software as a Service - sold as a product (normally subscription)")]
        [Required(ErrorMessage = "Please select a value")]
        [JsonProperty(PropertyName = "softwareAsAService")]
        public int? SoftwareAsAService { get; set; }

        [DisplayName("Other")]
        [Description("Any other type of software not listed above")]
        [Required(ErrorMessage = "Please select a value")]
        [JsonProperty(PropertyName = "other")]
        public int? Other { get; set; }
    }
}

Injected as:

    [Inject]
    private Models.SoftwareTypes Model { get; set; }

Your Experiences page:

State defined as:

namespace SoftwareSurvey.Models
{
    public class Experiences
    {
        [DisplayName("ROI")]
        [Description("Is it providing Return On Investment?")]
        [Required(ErrorMessage = "Please select a value")]
        [JsonProperty(PropertyName = "returnOnInvestment")]
        public int? ReturnOnInvestment { get; set; }

        [DisplayName("Keeping pace")]
        [Description("Is it keeping pace with the business needs?")]
        [Required(ErrorMessage = "Please select a value")]
        [JsonProperty(PropertyName = "keepingPace")]
        public int? KeepingPace { get; set; }

        [DisplayName("Recruitment")]
        [Description("It is easy to recruit the developers you want?")]
        [Required(ErrorMessage = "Please select a value")]
        [JsonProperty(PropertyName = "recruitment")]
        public int? Recruitment { get; set; }

        [DisplayName("Retention")]
        [Description("Is it easy to retain your developers?")]
        [Required(ErrorMessage = "Please select a value")]
        [JsonProperty(PropertyName = "retention")]
        public int? Retention { get; set; }

        [DisplayName("Quality")]
        [Description("Is the software of a high quality?")]
        [Required(ErrorMessage = "Please select a value")]
        [JsonProperty(PropertyName = "quality")]
        public int? Quality { get; set; }

        [DisplayName("Predicability")]
        [Description("Is the software development predicatable?")]
        [Required(ErrorMessage = "Please select a value")]
        [JsonProperty(PropertyName = "predicability")]
        public int? Predicability { get; set; }
    }
}

Injected as:

    [Inject]
    private Models.Experiences Model { get; set; }

One Change page:

State defined as:

namespace SoftwareSurvey.Models
{
    public class OneChange
    {
        [JsonProperty(PropertyName = "text")]
        public string Text { get; set; }
    }
}

Injected as:

    [Inject]
    private Models.OneChange Model { get; set; }

Further Contact page:

State defined as:

namespace SoftwareSurvey.Models
{
    public class Contact : IValidatableObject
    {
        [DisplayName("With the results of the survery?")]
        [JsonProperty(PropertyName = "resultsOfTheSurvey")]
        public bool SurveyResults { get; set; }

        [DisplayName("For any follow up questions?")]
        [JsonProperty(PropertyName = "followUpQuestions")]
        public bool FollowUpQuestions { get; set; }

        [DisplayName("For future surveys?")]
        [JsonProperty(PropertyName = "furtherSuvey")]
        public bool FurtherSurveys { get; set; }

        [DisplayName("Email Address")]
        [EmailAddress]
        [JsonProperty(PropertyName = "email")]
        public string Email { get; set; }

        public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
        {
            return IsEmailValid ? null : new ValidationResult[] { new ValidationResult("Please provided email", new string[] { "Email" }) };
        }

        private bool IsEmailValid => !RequiresEmailAddress || !string.IsNullOrEmpty(Email);
        private bool RequiresEmailAddress => SurveyResults || FollowUpQuestions || FurtherSurveys;
    }
}

Injected as:

    [Inject]
    private Models.Contact Model { get; set; }

Saving the results

On hitting the final page, the application saves the full state object for the user to Cosmos DB - as discussed in part 6

The survey is then complete for the user.

Supporting cast

While not directly related to the application itself, its obvious right to draw attention to the supporting functions.

The following allowed me work quickly by providing a safety net (mainly to avoid regression):

bUnit for Unit testing - see Part 8
End to End testing - see Part 9
Continous Integration, Delivery and Deployment - see Part 11

And that's it

The full source code (including tests, Bicep/ ARM templates and Azure DevOps pipeline YAML) can be found in this repo.

There is however one further article to the series. I take a look at the different upgrading to .Net 5 makes to my Blazor Server application.

Building a Software Survey using Blazor - Part 11 - Azure DevOps

Mark Taylor — Mon, 14 Dec 2020 13:50:12 +0000

I've decided to write a small survey site using Blazor. Part of this is an excuse to learn Blazor.

As I learn with Blazor I will blog about it as a series of articles.

This series of articles is not intended to be a training course for Blazor - rather my thought process as I go through learning to use the product.

Earlier articles in this series:

I generally use Azure DevOps for my personal projects. Azure DevOps is described as:

"Azure DevOps provides developer services to support teams to plan work, collaborate on code development, and build and deploy applications." Source

And for the purposed of Continious Integration, Delivery and Deployment, I use the Pipelines service of Azure DevOps.

What's in a name?

Personally I'd rather that Microsoft marketing hadn't decided to use the name "DevOps" for the collected services.

I can understand why they chose it - but it only adds to the confusion over what DevOps is.

DevOps is not a product. DevOps is not a job role. DevOps is much wider than that.

I love the definition of DevOps from Donovan Brown (of Microsoft):

"DevOps is the union of people, process, and products to enable continuous delivery of value to our end users." Source

I actually preferred the services pervious name "Visual Studio Team Services" or "VSTS" - but I can also see that as being rather limiting.

Pipelines

The Pipelines service of Azure DevOps provides build and deployment services similar to Circle CI, TeamCity, Jenkins, Octopus Deploy, etc.

It often seems to be overlooked as a CI/ CD tool - but is actually very good.

For this project, I defined 3 "pipelines":

Build, Test and Deploy
Production Smoke Test
E2E Test

The Build, Test and Deploy pipeline

As the name suggests, on commit of any change to Github, the pipeline will build, test and deploy the Blazor Server app to an Azure App Service.

The pipelines will:

Restore nuget packages
Build the Software Survey solution
Run the Unit Tests (the SoftwareSurvey.UnitTests and SoftwareSurvey.Models.UnitTests projects)
Publish the Software Survey app
Deploy to the Software Survey app to Azure App Services
Copy and Publish the End to End Tests (the SoftwareSurvey.E2ETests project)

This is all fairly standard stuff - the YAML for the pipeline can be found here on GitHub.

The Production Smoke Test pipeline

The Production Smoke Test was scheduled to run every hour while the survey was open (the month of September).

The Production Smoke Test would use the End to End tests Published by the Buid, Test and Deploy pipeline to run them against the production site.

I was effectively using the pipeline to run a synthetic transaction through the production app on a regular basis - using the standard pipeline notification capability to alert if the test failed.

The pipeline will:

Download the E2E Tests (from the Build, Test and Deploy pipeline) to the agent
Configure the Chrome Web Driver (needed for the End to End tests)
Run the test
Publish the final screen of the test - this allowed me to review what the app looked like if the test failed

The YAML for this pipeline can be found here on GitHub.

The E2E Test pipeline

This is the most complicated of the pipelines - and the least used.

I wanted a full end to end build of the environment, deploy the app, test it and destroy the environment pipeline - and this is it.

I generally only run this manually - but in a client environment, I would probably look to incorporate into the Build, Test and Deploy.

Because this is standing up Azure services (Cosmos DB and SignalR), this test does take longer to run (just over 20 minutes).

The pipeline will:

Create the Azure environment - using ARM template generated by Bicep that I talked about in part 10
Get the output values from the ARM template - these are used later when running the E2E tests
Download the app (from Build, Test and Deploy pipeline)
Deploy the app new environment
Download the E2E Tests (from the Build, Test and Deploy pipeline) to the agent
Configure the Chrome Web Driver (needed for the End to End tests)
Run the test
Publish the final screen of the test
Remove the Azure environment

The YAML for this pipeline can be found here on GitHub

Key takeaway for Blazor Server

In short, when it comes to CI/ CD - there isn't really anything special we need to do for Blazor Server. It’s just like deploying any ASP.Net application.

Yes we may need different services to support it (mainly the SignalR), but that is just part of the ARM setup (assuming you deploy from scratch).

In the next article, I'll talk about pulling all of this together for the final solution.

Building a Software Survey using Blazor - Part 10 - Bicep

Mark Taylor — Mon, 07 Dec 2020 20:49:10 +0000

I've decided to write a small survey site using Blazor. Part of this is an excuse to learn Blazor.

As I learn with Blazor I will blog about it as a series of articles.

This series of articles is not intended to be a training course for Blazor - rather my thought process as I go through learning to use the product.

Earlier articles in this series:

I host my Software Survey site on Azure - not that much of as surprise given the use of both Azure Cosmos DB and Azure SignalR Service.

And I want to document my setup as Infrastructure as Code (IaC) so that it would repeatable and reliable.

Normally I would use the Azure ARM template format.

But given I was already being experimental using Blazor ... why not try something new for the infrastructure as well.

Enter Bicep.

Bicep

Bicep is an open-source project from the Microsoft Azure team - who describe it as:

"Bicep is a Domain Specific Language (DSL) for deploying Azure resources declaratively. It aims to drastically simplify the authoring experience with a cleaner syntax and better support for modularity and code re-use. Bicep is a transparent abstraction over ARM and ARM templates, which means anything that can be done in an ARM Template can be done in bicep" Bicep Github

They also caveat it with:

"Note: Bicep is currently an experimental language and we expect to ship breaking changes in future releases. It is not yet recommended for production usage."

And yet for something very experimental, it really does seem to work very well.

Abstractions over cloud templating languages

I've found ARM templates, like AWS CloudFormation templates, to be very verbose - and can be rather cumbersome to work with.

For AWS work, I've really enjoyed using their Cloud Development Kit as a much better option. The AWS CDK allows you to "develop" your infrastructure using a variety of development languages (although TypeScript is probably the best choice).

For example (taken from AWS Documentation):

import * as cdk from '@aws-cdk/core';
import * as s3 from '@aws-cdk/aws-s3';

export class HelloCdkStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    new s3.Bucket(this, 'MyFirstBucket', {
      versioned: true
    });
  }
}

This defines a new CloudFormation stack with an S3 bucket in it.

AWS CDK then will compile this into a standard CloudFormation template.

And at a high level, Azure Bicep operates in much the same way.

It allows you to define your infrastructure in a domain specific language (rather than a general purpose programming language like AWS CDK) and then compiles to an ARM template.

My infrastructure

Here is the Bicep file for a full infrastructure (source)

param environment string = 'e2e'

var nameprefix = 'rfc-${environment}-software-survey'

resource signalr 'Microsoft.SignalRService/SignalR@2020-07-01-preview' = {
    name: '${nameprefix}-signalr'
    location: resourceGroup().location
    kind: 'SignalR'
    sku: {
        name: 'Free_F1'
    }
}

resource cosmos 'Microsoft.DocumentDB/databaseAccounts@2020-06-01-preview' = {
    name: '${nameprefix}-db'
    location: resourceGroup().location
    kind: 'GlobalDocumentDB'
    properties: {
        enableFreeTier: true
        databaseAccountOfferType: 'Standard'
        consistencyPolicy: {
            defaultConsistencyLevel: 'Session'
        }
    }
}

resource applicationInsights 'microsoft.insights/components@2018-05-01-preview' = {
    name: '${nameprefix}-application-insights'
    location: resourceGroup().location
    kind: 'web'
    properties: {
        ApplicationType: 'web'
        publicNetworkAccessForIngestion: 'Enabled'
        publicNetworkAccessForQuery: 'Enabled'
    }
}

resource farm 'Microsoft.Web/serverfarms@2018-11-01' = {
    name: '${nameprefix}-app-plan'
    location: resourceGroup().location
    kind: 'linux'
    sku: {
        name: 'F1'
        capacity: 1
    }
}

resource website 'Microsoft.Web/sites@2018-11-01' = {
    name: '${nameprefix}-web-app'
    location: resourceGroup().location
    kind: 'app'
    properties: {
        serverFarmId: farm.id
        siteConfig: {
            appSettings: [
                {
                    name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
                    value: reference(applicationInsights.id).InstrumentationKey
                }
                {
                    name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
                    value: reference(applicationInsights.id).ConnectionString
                }
                {
                    name: 'ApplicationInsightsAgent_EXTENSION_VERSION'
                    value: '~2'
                }
                {
                    name: 'Azure__SignalR__ConnectionString'
                    value: listKeys(signalr.id, '2020-07-01-preview').primaryConnectionString
                }
                {
                    name: 'Persistance:CosmosDbEndpoint'
                    value: cosmos.properties.documentEndpoint
                }
                {
                    name: 'Persistance:CosmosDbPrimaryKey'
                    value: listKeys(cosmos.id, '2020-06-01-preview').primaryMasterKey
                }
                {
                    name: 'XDT_MicrosoftApplicationInsights_Mode'
                    value: 'default'
                }
            ]
        }
    }
}

output appServiceName string = website.name
output appServiceUrl string = 'http://${website.name}.azurewebsites.net/'
output cosmosEndpoint string = cosmos.properties.documentEndpoint
output cosmosPrimaryKey string = listKeys(cosmos.id, '2020-06-01-preview').primaryMasterKey

In it I:

Create a SignalR Service - free tier
Create a Cosmos DB - free tier
Create an Application Insights
Create an App Service farm - free tier
Create an App Service - passing in all the app settings needed by the Survey app

These 92 lines then get compiled into 129 line ARM template - which can be seen here

Benefits

Mainly, I think that Bicep is considerably more readable than native ARM template.

Bicep is also handling an amount of default values for you.

It is however early days for the tool. As of writing, they have only just moved to Bicep 0.2 - and I've yet to try (there could potentially be breaking changes).

I currently wouldn't recommend for a client's production use - unless they had an appetite for the bleeding edge.

For my purpose however, given it still generated a valid ARM template, I'm more than happy to use it.

A note on Terraform

If you have much experience with IaC, you maybe reading this and asking why I didn't go with Terraform.

To be blunt, I've never really found the opportunity to use Terraform. While I've studied it, my clients are generally working with native template formats.

I would see no problems using Terraform to create the infrastructure.

Outputs

You may have noted that I output a number of values at the end of my script:

output appServiceName string = website.name
output appServiceUrl string = 'http://${website.name}.azurewebsites.net/'
output cosmosEndpoint string = cosmos.properties.documentEndpoint
output cosmosPrimaryKey string = listKeys(cosmos.id, '2020-06-01-preview').primaryMasterKey

Those outputs are passed to my End to End tests (introduced in the last article).

Thank you for reading. See you in the next article.

Building a Software Survey using Blazor - Part 9 - End to End tests

Mark Taylor — Mon, 30 Nov 2020 13:44:19 +0000

I've decided to write a small survey site using Blazor. Part of this is an excuse to learn Blazor.

As I learn with Blazor I will blog about it as a series of articles.

This series of articles is not intended to be a training course for Blazor - rather my thought process as I go through learning to use the product.

Earlier articles in this series:

While in the last artice I talked about unit testing with bUnit - in this article I want to talk about end to end testing.

I find a lot of value in automating at least the happy path test for user journeys.

Firstly it save me running through the journey manually every time I make a code change - great for spotting regression. And secondly, if possible, I like to use the same test for synthetic testing of production systems. Using the test to run through the production journey on a regular interval as a way of highlighting any problems.

Thus, for my Software Survey, I wanted to implement a simple happy path test that exercised every page of the survey and then validated the survey results has been correctly persisted to Azure Cosmos DB.

To SpecFlow or not to SpecFlow

Normally I'd use SpecFlow to provide the test in its Gerkin style language.

In this instance, as it is only me working on the project, I've just used an xUnit test. I may add SpecFlow over the top at some point - but all it would add is increased readability - which has a lot of value when taking a client through the test - but not so much when it’s just for myself.

Nothing special

If I'm honest, there is nothing particularly special in creating the end to end test.

The test is written in xUnit and uses Selenium Web Driver to interact with the website.

Which is quite a positive.

A Blazor Server is producing a HTML, CSS & JavaScript website, there appears to be no reason that the Selenium Web Driver can't be used to navigate it. I would also suspect that Cypress should work - but I don't have as much experience with it, so stuck with the known combination of xUnit & the Selenium Web Driver.

So, the test should be easy right?

Here be dragons ...

I have to admit that the end to end tests possibly cased me more problems than anything else with Blazor.

The initial version of the test seemed to work fine.

I could run the test locally - it worked.

I could run the test as part of Continuous Deployment - it worked.

I could setup to run on an hourly schedule against production for synthetic testing - it sometimes worked.

And this “sometimes” became a huge frustration to me. It could work for hours - if not days, then the test would start reporting failures. I would check manually, and it would look to be working fine.

If you look at the actual test class you'll see I've added various helper methods when trying to access page elements.

Mainly the helpers are set to retry if the application is not in the expected state:

        private async Task RetryActivity(By by, Func<IWebElement, bool> activity, string activityDescription)
        {
            _testOutputHelper.WriteLine($"Attempting '{activityDescription}'");

            // Allow time for Blazor to do its thing (fail after 60 attempt - 30 seconds)
            for (int i = 0; i < 60; i++)
            {
                await Task.Delay(500);

                try
                {
                    var element = _driver.FindElement(by);

                    if (activity(element)) return;

                    _testOutputHelper.WriteLine("Activity failed to return true");
                }
                catch (NoSuchElementException)
                {
                    _testOutputHelper.WriteLine("NoSuchElementException received");
                    continue;
                }
                catch (StaleElementReferenceException)
                {
                    _testOutputHelper.WriteLine("StaleElementReferenceException received");
                    continue;
                }
                catch (Exception ex)
                {
                    _testOutputHelper.WriteLine($"Exception {ex.GetType().Name} encountered - {ex.Message}");
                    throw ex;
                }
            }

            _testOutputHelper.WriteLine("Maximum retries reached");
            throw new Exception($"Maximum retries reached while attempting '{activityDescription}'");
        }

                private async Task WaitForElement(By by)
        {
            // Allow time for Blazor to do its thing (fail after 60 attempt - 30 seconds)
            for (int i = 0; i < 60; i++)
            {
                await Task.Delay(500);

                try
                {
                    _driver.FindElement(by);
                }
                catch (NoSuchElementException)
                {
                    continue;
                }
                catch (StaleElementReferenceException)
                {
                    continue;
                }
                return;
            }
        }

As you can see ... lots of waits ... lots or retries.

And this was because Selenium was struggling to find elements reliably.

But, as discussed in part 4, I was looking in the wrong place.

Render Mode

As I talk about in part 4, the ServerPreRendered mode will initially serve a static copy of the page and then hydrate it once the Blazor (including SignalR) is fully available.

And this was at the heart of my problem.

For some reason the hourly tests seemed to be more suseptable to it than any other method of running the test - possible because the survey site was colder to start.

Once I added the PreRenderLoadingMessage to the survey site, the end to end tests consistently passed.

And getting to that gem cost me a considerable amount of time - and sanity.

Tidy up

I should be able to remove a fair amount of my retry logic from the end to end test now that I've found the true source of the problem.

To be honest though, I don't see any benefit in doing that. It is all working, so I'm inclined to leave it as it is.

And that's it for the end to end tests.

For something that was actually so easy to setup and operate, the overhead of understanding the ServerPreRendered mode really caught me out.

But I know it for next time. This is why we try new things.

Thank you for reading. See you in the next article where I introduce Bicep – a DSL for configuring Azure.

Building a Software Survey using Blazor - Part 8 - bUnit

Mark Taylor — Mon, 23 Nov 2020 13:52:56 +0000

I've decided to write a small survey site using Blazor. Part of this is an excuse to learn Blazor.

As I learn with Blazor I will blog about it as a series of articles.

This series of articles is not intended to be a training course for Blazor - rather my thought process as I go through learning to use the product.

Earlier articles in this series:

In modern development it would be difficult for any new technology to gain traction without an ability to unit test.

For Blazor that is bUnit.

I have to admit I was a little surprised to find that Microsoft didn't have its own tools for Blazor - rather they actually promote a 3rd party open-source tool:

"There's no official Microsoft testing framework for Blazor, but the community-driven project bUnit provides a convenient way to unit test Blazor components." Microsoft Docs

While I really like that Microsoft is embracing the open-source community, it does feel a little odd that they didn't have their own offering.

That being said, bUnit seems an exceptionally well developed and maintained tool.

I'd certainly recommend reading through the bUnit documentation site before making a start. The documentation is very good and quite quick to run through.

A summary

So bUnit works with xUnit, NUnit or MSTest - providing a number of helpers tools for Blazor component testing.

I believe that bUnit favours xUnit - which is fine for me as xUnit is my go-to unit testing framework for dotnet.

bUnit allows you to write your tests in 3 ways:

C# style
Razor Fixture
Razor Snapshot

C# Style

This is a fairly traditional style which should be fairly recognisable to anyone with xUnit experience (below taken from the bUnit Docs):

using Xunit;
using Bunit;

namespace Bunit.Docs.Samples
{
  public class HelloWorldTest
  {
    [Fact]
    public void HelloWorldComponentRendersCorrectly()
    {
      // Arrange
      using var ctx = new TestContext();

      // Act
      var cut = ctx.RenderComponent<HelloWorld>();

      // Assert
      cut.MarkupMatches("<h1>Hello world from Blazor</h1>");
    }
  }
}

The key here is the TestContext - it is part of bUnit and provides all the magic needed to interact with the Blazor components.

Razor Fixture

These tests are written differently, they are written in the Razor syntax. The Fixture testing then allows you to make similar assertions that you can within C# style (sample taken from the bUnit Documentation Page):

@inherits TestComponentBase

<Fixture Test="HelloWorldComponentRendersCorrectly">
  <ComponentUnderTest>
    <HelloWorld />
  </ComponentUnderTest>

  @code
  {
    void HelloWorldComponentRendersCorrectly(Fixture fixture)
    {
      // Act
      var cut = fixture.GetComponentUnderTest<HelloWorld>();

      // Assert
      cut.MarkupMatches("<h1>Hello world from Blazor</h1>");
    }
  }
</Fixture>

The main difference here is that setup in done through Razor syntax.

Personally I favour the C# style - and at this time, I've not found a reason to use the Razor Fixture style. I suspect that it is largely a matter of personal taste.

Blazor Snapshot

These tests are also writen using Razor syntax - but rather than normal assertions, you specify the expected output (sample take from the bUnit Documentation Page):

@inherits TestComponentBase

<SnapshotTest Description="HelloWorld component renders correctly">
  <TestInput>
    <HelloWorld />
  </TestInput>
  <ExpectedOutput>
    <h1>Hello world from Blazor</h1>
  </ExpectedOutput>
</SnapshotTest>

Now this works very well for regression style testing.

I've used this across a number of my components to ensure that I pick up any accidental changes. For this I think that Snapshot testing works very well.

This has been exceptionally useful for testing my OptionGrid component. It’s probably my most complex component involving an amount of reflection and dynamic generation. Ultimately it provides the grid during the survey:

Technically my Snapshot test is more of an integration test - as it uses multiple components, but for regression purposes it’s great. In the test, I define a sample model to use:

@inherits TestComponentBase

<SnapshotTest Description="Options Grid renders correctly">
    <TestInput>
        <CascadingValue Value="EditContext">
            <OptionGrid NotApplicableLabel="N/A" TValue="Model" />
        </CascadingValue>
    </TestInput>
    <ExpectedOutput>
        <div class="option-grid">
            <span class="header"></span>
            <span class="header">N/A</span>
            <span class="header"></span>
            <span class="header">(Not) 1</span>
            <span class="header">2</span>
            <span class="header">3</span>
            <span class="header">4</span>
            <span class="header">(Very) 5</span>
            <hr>
            <span>Value 1 Name</span>
            <input type="radio" name="value-1" checked="">
            <span></span>
            <input type="radio" name="value-1">
            <input type="radio" name="value-1">
            <input type="radio" name="value-1">
            <input type="radio" name="value-1">
            <input type="radio" name="value-1">
            <i class="option-grid-row-description">Value 1 Description</i>
            <hr>
            <span>Value 2 Name</span>
            <input type="radio" name="value-2" checked="">
            <span></span>
            <input type="radio" name="value-2">
            <input type="radio" name="value-2">
            <input type="radio" name="value-2">
            <input type="radio" name="value-2">
            <input type="radio" name="value-2">
            <i class="option-grid-row-description">Value 2 Description</i>
            <hr>
            <span>Value 3 Name</span>
            <input type="radio" name="value-3" checked="">
            <span></span>
            <input type="radio" name="value-3">
            <input type="radio" name="value-3">
            <input type="radio" name="value-3">
            <input type="radio" name="value-3">
            <input type="radio" name="value-3">
            <i class="option-grid-row-description">Value 3 Description</i>
            <hr>
        </div>
    </ExpectedOutput>
</SnapshotTest>

@code
{
    public EditContext EditContext = new EditContext(new Model());

    public class Model
    {
        [System.ComponentModel.DisplayName("Value 1 Name")]
        [System.ComponentModel.Description("Value 1 Description")]
        [System.ComponentModel.DataAnnotations.Required(ErrorMessage = "Value 1 is required")]
        public int Value1 { get; set; }

        [System.ComponentModel.DisplayName("Value 2 Name")]
        [System.ComponentModel.Description("Value 2 Description")]
        [System.ComponentModel.DataAnnotations.Required(ErrorMessage = "Value 2 is required")]
        public int Value2 { get; set; }

        [System.ComponentModel.DisplayName("Value 3 Name")]
        [System.ComponentModel.Description("Value 3 Description")]
        [System.ComponentModel.DataAnnotations.Required(ErrorMessage = "Value 3 is required")]
        public int Value3 { get; set; }
    }
}

Note that use of the EditContext round the sample model. This is provided into the component via the <CascadingValue/>.

I do have other tests that around the sub-components of this component, but having this Snapshot test allows for confidence on regression.

Unit Testing with the NavigationManager

I'd have liked to think that Microsoft would have learnt by now to always use interfaces rather than concrete objects - and in a lot of Blazor that is true.

Unfortunately, not with the NavigationManager.

The NavigationManager is part of Blazor and used to change "page" within the application.

So when it comes to unit testing a component that uses the NavigationManager we have a problem.

Luckily, due to the necessity of having to deal with a history of Microsoft concrete implementations, it’s a fairly simple approach to resolve.

I've simple created an interface for INavigationManager, then a simple wrapper that supports the interface and calls the concrete NavigationManager under the hood, then set up my component to use the INavigationManager:

namespace SoftwareSurvey.Wrappers
{
    public interface INavigationManager
    {
        string Uri { get; }
       void NavigateTo(string uri);
    }
}

using Microsoft.AspNetCore.Components;

namespace SoftwareSurvey.Wrappers
{
    public class NavigationManagerWrapper : INavigationManager
    {
        private readonly NavigationManager NavigationManager;

        public NavigationManagerWrapper(NavigationManager navigationManager)
        {
            NavigationManager = navigationManager;
        }

        public void NavigateTo(string uri) => NavigationManager.NavigateTo(uri);

        public string Uri => NavigationManager.Uri;
    }
}

<div class="form-group navigation-buttons">
    @if (HasPrevious)
    {
        <button type="button" class="btn previous-navigation-button" @onclick="HandlePrevious">Previous</button>
    }
    @if (HasNext)
    {
        <button type="submit" class="btn next-navigation-button" @onclick="HandleNext">Next</button>
    }

    <div class="clear"></div>
</div>

@code {
    [Inject]
    private SoftwareSurvey.Wrappers.INavigationManager NavigationManager { get; set; }

    ...
}

Then when it comes to testing, I can use the Moq library to create Mock<INavigationManager> and test with ease.

Unit Testing with StateHasChanged()

In part 4, I talked about my <PreRenderLoadingMessage /> component; it showed a loading message while the app was starting up (establishing SignalR, etc), then would show the app content when everything was ready.

Unit testing this became a problem due to the use of StateHasChanged().

Ideally I wanted two tests - one to validate the loading message was showing BEFORE the app was ready and one to validate the content was showing AFTER the app was ready.

The problem with the StateHasChange() was that it was forcing the second render before I had a chance to validate the BEFORE state.

So to test, I did something that I generally advise against - added unit testing specific code to the component in question.

To the component I added an extra parameter (UnitTestMode) which would control if the StateHasChanged() would trigger or not.

@if (HasRendered)
{
    @ChildContent
}
else
{
    <LoadingSpinner Title="Loading ..." />
}


@code {
    [Parameter]
    public bool UnitTestMode { get; set; }

    [Parameter]
    public RenderFragment ChildContent { get; set; }

    private bool HasRendered { get; set; }

    protected override void OnAfterRender(bool firstRender)
    {
        if (firstRender)
        {
            HasRendered = true;

            if (!UnitTestMode)
            {
                StateHasChanged();
            }
        }
    }
}

Then in my test, I had more control over the renders. By setting the UnitTestMode to true, I could specify exactly when the second render occurred:

        [Fact]
        public void ShowsLoadingMessage_OnFirstRender()
        {
            using var context = new TestContext();
            context.Services.AddSingleton(new Mock<IEventLoggingService>().Object);

            IRenderedComponent<PreRenderLoadingMessage> cut = context.RenderComponent<PreRenderLoadingMessage>(parameters =>
                parameters
                    .Add(p => p.UnitTestMode, true)
                    .AddChildContent("<div>Hello World</div>")
            );

            Assert.Contains("Loading ...", cut.Markup);
        }

        [Fact]
        public void ShowsChildContent_OnSecondRender()
        {
            using var context = new TestContext();
            context.Services.AddSingleton(new Mock<IEventLoggingService>().Object);

            IRenderedComponent<PreRenderLoadingMessage> cut = context.RenderComponent<PreRenderLoadingMessage>(parameters => 
                parameters
                    .Add(p => p.UnitTestMode, true)
                    .AddChildContent("<div>Hello World</div>")
            );

            Assert.DoesNotContain("<div>Hello World</div>", cut.Markup);

            cut.Render();
            Assert.Contains("<div>Hello World</div>", cut.Markup);
        }

And then just to provide a level of confort, I also test for when the UnitTestMode is off - which we know will automatically re-render due to the StateHasChanged().

        [Fact]
        public void ShowsChildContent_IfInDefaultMode()
        {
            using var context = new TestContext();
            context.Services.AddSingleton(new Mock<IEventLoggingService>().Object);

            IRenderedComponent<PreRenderLoadingMessage> cut = context.RenderComponent<PreRenderLoadingMessage>(parameters =>
                parameters.AddChildContent("<div>Hello World</div>")
            );

            Assert.Contains("<div>Hello World</div>", cut.Markup);
        }

As I say, I would normally advise against adding this sort of change directly to a component - specifically for the purposes of testing - but in this case I believe it is valid and safe enough.

I believe there are plans to allow for an async version of the StateHasChanged() - partly for this, and partly to batch the rendering of multiple changes (for performance) - so I may change to that once it is available.

Other examples

I've not gone into details of how to use bUnit as I believe the documentation site does an excellent job of it.

If however, you want to see more example of how I've used, then look at the github for the Software Survey UnitTests project.

Next time

Next time I'm going to take a look at end to end testing using Selenium and xUnit.

Building a Software Survey using Blazor - Part 7 - Azure SignalR Service

Mark Taylor — Mon, 16 Nov 2020 13:52:47 +0000

I've decided to write a small survey site using Blazor. Part of this is an excuse to learn Blazor.

As I learn with Blazor I will blog about it as a series of articles.

This series of articles is not intended to be a training course for Blazor - rather my thought process as I go through learning to use the product.

Earlier articles in this series:

SignalR is at the heart of Blazor server. It forms the realtime connection so that the server can send updates to the browser.

SignalR is describes as:

"SignalR is a free and open-source software library for Microsoft ASP.NET that allows server code to send asynchronous notifications to client-side web applications. The library includes server-side and client-side JavaScript components."

But it is almost an invisible part of Blazor - it just happens.

For production use however, you really want to be using an Azure SignalR Service as it takes a lot of the strain off the server and allows for greater scaling.

"We recommend using the Azure SignalR Service for Blazor Server apps. The service allows for scaling up a Blazor Server app to a large number of concurrent SignalR connections. In addition, the SignalR service's global reach and high-performance data centers significantly aid in reducing latency due to geography." Source

Creating an Azure SignalR Service

Again, like Azure Cosmos DB, there is a free tier.

Its intended for development & test, but given the expected usage of my survey, it was to be sufficient for my use.

Creating via the Azure Portal is easy and provides you with the relevant credentials. (In a future article, I'll show how to create with Azure Bicep - a Domain-Specific-Language for producing ARM templates).

You'll need the connection string from the service.

For production, I run the Blazor Server App as an Azure App Service, thus set the environment variable (Configuration -> Application Setting) Azure__SignalR__ConnectionString to the connection string (more on this in the Azure Bicep article).

For development, I set the User Secret of Azure:SignalR:ConnectionString.

The important thing is to make sure that the connection string is NOT stored in source control (especially as I'm using a public Github repository).

Configuring Blazor app to use the Azure SignalR Service

With Startup.cs add:

        public void ConfigureServices(IServiceCollection services)
        {
            ...

            services.AddSignalR().AddAzureSignalR();

            ...
        }

And within appsettings.json, then add:

  "Azure": {
    "SignalR": {
      "Enabled": "true",
      "ServerStickyMode": "Required"
    }
  }

Scaffolding

A lot of this setup is done for you if you scaffold the SignalR Service connection - either when you create the Blazor Server app at the start or by the "Connected Services".

Once all of this is done, it should just all work.

Its almost too easy. And so far I've found no problems with it.

Building a Software Survey using Blazor - Part 6 - Azure CosmosDB

Mark Taylor — Mon, 09 Nov 2020 13:50:03 +0000

I've decided to write a small survey site using Blazor. Part of this is an excuse to learn Blazor.

As I learn with Blazor I will blog about it as a series of articles.

This series of articles is not intended to be a training course for Blazor - rather my thought process as I go through learning to use the product.

Earlier articles in this series:

When it came to storing the survey results, I wanted something simple.

But in the same respect I wanted something cheap - and that would allow me report on the collected data.

About this time, Azure launched a free tier of Cosmos DB (or at least about this time I noticed it).

I'd used Cosmos DB in its easlier incarnation - DocumentDB - but hadn't used Cosmos DB itself due to the cost.

The free tier allows for a reasonable amount of data - more than enough for the survey, so I decided to trial it for the app.

Local Development

Firstly, for development, its good to know that Microsoft provide a local Cosmos DB emulator.

This can be downloaded from here and is a good way to get started with Cosmos DB without the danger of incurring any Azure charges.

IPersistanceManager

So I could inject Cosmos DB in, I wanted to hide the persistance being an interface:

    public interface IPersistanceManager
    {
        Task<bool> Persist(SurveyResponse surveyResponse);
    }

Which of course allowed me to mock out the PersistanceManager for integration testing. So for example;

    public class FakePersistanceManager : IPersistanceManager
    {
        public async Task<bool> Persist(SurveyResponse surveyResponse)
        {
            await Task.Run(() => Thread.Sleep(5000));
            return true;
        }
    }

CosmosDbPersistanceManager.cs

The actual concrete implementation for Azure Cosmos DB was fairly simple. On Persist, it would create a CosmosClient (using credentials from config), create the database & container if either didn't exist, and then save passed in model:

using Microsoft.Azure.Cosmos;
using Microsoft.Extensions.Logging;
using SoftwareSurvey.Models;
using System;
using System.Net;
using System.Threading.Tasks;

namespace SoftwareSurvey.Services
{
    public class CosmosDbPersistanceManager : IPersistanceManager
    {
        private const string APPLICATION_NAME = "SoftwareSurvery";
        private const string DATABASE_NAME = "SoftwareSurvey";
        private const string CONTAINER_NAME = "Responses";

        private readonly PersistanceConfiguration _configuration;
        private readonly ILogger _logger;

        public CosmosDbPersistanceManager(PersistanceConfiguration configuration, ILogger<CosmosDbPersistanceManager> logger)
        {
            _configuration = configuration;
            _logger = logger;
        }

        public async Task<bool> Persist(SurveyResponse surveyResponse)
        {
            try
            {
                var client = new CosmosClient(_configuration.CosmosDbEndpoint,
                                              _configuration.CosmosDbPrimaryKey,
                                              new CosmosClientOptions() { ApplicationName = APPLICATION_NAME });

                Database database = await client.CreateDatabaseIfNotExistsAsync(DATABASE_NAME);
                Container container = await database.CreateContainerIfNotExistsAsync(CONTAINER_NAME, "/year");

                ItemResponse<SurveyResponse> response = await container.CreateItemAsync<SurveyResponse>(surveyResponse, new PartitionKey(surveyResponse.Year));

                if (response.StatusCode == HttpStatusCode.Created)
                {
                    return true;
                }
                else
                {
                    _logger.LogError($"Unable to save record to CosmosDB - received {response.StatusCode} - {response.ActivityId}");
                    return false;
                }
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "Failed to save to CosmosDB");

                return false;
            }
        }
    }
}

ThankYou.razor

The CosmosDbPersistanceManager could then be injected into the ThankYou page (the final page).

The ThankYou page would show a "saving" message while the response was being saved to Cosmos DB and provide retry prompt if the save failed:

@page "/ThankYou"

@if (Saved)
{
    if (Error)
    {
        <h1 class="temporary-header">SORRY</h1>
        <p>An error has occurred while trying to save your details.</p>
        <p>Please press the button below to retry:</p>
        <button type="submit" class="btn retry-button" @onclick="HandleRetry">Retry</button>
    }
    else
    {
        <PageTitle Title="THANK YOU" Position="7" />
        ...
    }
}
else
{
    <LoadingSpinner Title="SAVING ..."></LoadingSpinner>
}

@code
{
    [Inject]
    private Models.SurveyResponse Model { get; set; }
    [Inject]
    private Services.IPersistanceManager PersistanceManager { get; set; }

    private bool Saved { get; set; }
    private bool Error { get; set; }

    protected override void OnAfterRender(bool firstRender)
    {
        if (firstRender)
        {
            SaveData();
        }
    }

    private void HandleRetry(EventArgs eventArgs)
    {
        Saved = false;
        Error = false;
        StateHasChanged();

        SaveData();
    }

    private void SaveData()
    {
        var task = PersistanceManager.Persist(Model);
        task.ContinueWith(async x =>
        {
            Error = !x.Result;
            Saved = true;
            await InvokeAsync(StateHasChanged);
        });

        Task.Run(() => task);
    }
}

Note that the actual Persist is run as a background task so that the user is shown the "Saving" message. On completion of the Persist then the UI is updated with with the Thank You message or the retry button.

And that's it

Fairly simple really.

And because I'm using the IPersistanceManager interface, I can subsitute fakes/ mocks during both development and testing.

It would also allow me to easily replace the persistance choice - moving to Azure SQL or even Blob storage if appropriate.

But I did feel that Azure Cosmos DB would have provided me with the a really good platform for data analysis. I'd certainly have liked to spend sometime with the Jupyter Notebook functionality - described by Microsoft as:

"Jupyter Notebook is an open-source web application that allows you to create and share documents that contain live code, equations, visualizations, and narrative text."

Unfortunately due to the lack of survey repondents, that isn't going to happen. Maybe next time.

Building a Software Survey using Blazor - Part 5 - Client IP

Mark Taylor — Mon, 12 Oct 2020 17:06:39 +0000

I've decided to write a small survey site using Blazor. Part of this is an excuse to learn Blazor.

As I learn with Blazor I will blog about it as a series of articles.

This series of articles is not intended to be a training course for Blazor - rather my thought process as I go through learning to use the product.

Earlier articles in this series:

One concern I has about running a survey, was how to avoid the results being swayed by a single party providing responses over and over again.

The simplest tactic to spot this was to record the client's IP address of the respondent and look for any bad behavior during the reporting stage.

In theory that should be simple, I just record the client's IP address and then save it along with the response.

The Problem

Normally for ASP.Net applications you would get the client's IP from the HttpContext.

At the time of writing however, Blazor did not have access to the HttpContext - see this Github issue.

I suspect this is something that will be resolved in future versions (possibly .Net 5), but this left me with a problem, how to get the client's IP without having access to the HttpContext.

The Solution

The solutions was actually reasonably simple - even if it took a few extra hops to achieve it.

First of all I grab the relevant details BEFORE starting the Blazor app and then pass them in:

_Hosts.cshtml

        @{
            var requestDetails = new SoftwareSurvey.Models.RequestDetails
            {
                ConnectionIpAddress = HttpContext.Connection.RemoteIpAddress.ToString(),
                ForwardedIpAddress = HttpContext.Request.Headers.ContainsKey("X-Forwarded-For") ? HttpContext.Request.Headers["X-Forwarded-For"].ToString() : null
            };
        }
        <app>
            <component type="typeof(App)" render-mode="ServerPrerendered" param-RequestDetails="requestDetails" />
        </app>

So before I invoke the Blazor app, I use standard ASP.Net functionality to populate a model with the RemoteIpAddress and any value in the X-Forwarded-For header. The X-Forwarded-For header should contain the original IP address if the request has come through a proxy.

While certainly not bulletproof, it was enough to capture silly attempts to game the responses.

The model was then passed in using the param-RequestDetails attribute notation. The param- prefix is a Blazor notation to then look for the parameter on the App object and populate it with the model.

App.razor

@inject SoftwareSurvey.Models.SurveyResponse _surveyResponse

...

@code {
    [Parameter]
    public SoftwareSurvey.Models.RequestDetails RequestDetails { get; set; }

    protected override Task OnInitializedAsync()
    {
        _surveyResponse.ConnectionIpAddress = RequestDetails.ConnectionIpAddress;
        _surveyResponse.ForwardedIpAddress = RequestDetails.ForwardedIpAddress;

        return base.OnInitializedAsync();
    }
}

The model is passed into the App via the RequestDetails property. I can then use those details to populate the _surveyResponse object which is used to track the respondent's answers - and ultimately is saved away into Azure Cosmos DB.

Added extra, the query string

In a similar manner, its also a useful technique to record query string values.

As part of my automated testing, I wanted to record that it was a test, thus could later be filtered out during the reporting phase.

To achieve this I wanted to be able to specify ?IsTest in the url so that it was marked in the _surveryResponse object - and saved away to Azure Cosmos DB for that later reporting.

So I simply added the following to the initialisation of the RequestDetails model in the _Hosts.cshtml:

IsTest = HttpContext.Request.QueryString.HasValue && HttpContext.Request.QueryString.Value.Contains("IsTest", StringComparison.InvariantCultureIgnoreCase)

And then set the property on the _surveyResponse object in the App.OnInitializedAsync:

_surveyResponse.IsTest = RequestDetails.IsTest;

Is this a better approach than using the HttpContext directly?

The HttpContext can often be a cause of problems for unit testing - especially if the unit testing is being added to existing code.

I often find that I create a wrapper around the HttpContext and then injecting the wrapper in to avoid direct HttpContext references.

The constraint of not having the HttpContext is arguably a good thing to avoid relying on direct references (which you really shouldn't).

By effectively treating the data as just another dependency to be passed in (via the [Parameter]) you are forcing the App to be cleaner - and thus easier to test.

So while I doubt it will be long before the HttpContext is made available with Blazor - for now it maybe a useful pattern.

Building a Software Survey using Blazor - Part 4 - Render Mode

Mark Taylor — Mon, 05 Oct 2020 17:27:47 +0000

I've decided to write a small survey site using Blazor. Part of this is an excuse to learn Blazor.

As I learn with Blazor I will blog about it as a series of articles.

This series of articles is not intended to be a training course for Blazor - rather my thought process as I go through learning to use the product.

Earlier articles in this series:

Your Blazor server side app will be initiated something like this in _Hosts.cshtml:

_Hosts.cshtml

        <app>
            <component type="typeof(App)" render-mode="ServerPrerendered" />
        </app>

I believe by default, the render-mode will be set to ServerPrerendered - and I think most examples will show render-mode with that option - and I have to admit I didn't really pay much attention to it until I struggled with my automated end-to-end tests.

My problem

I had built an end-to-end happy path test using Selenium and orchestrated it to run every hour using Azure DevOps. The test was fairly simple; it ran through every page of the survey with defined responses - then checked against CosmosDB to ensure that the survery results had been recorded.

I could run the test locally and it worked perfectly everytime.

And it would mostly work correctly when being run on the hourly schedule - but it wasn't consistent.

Occassionally I'd get failures. When I investigated it looked as if my Selenuim test simple wasn't pressing the "Next" button on the home page:

I experimented with various techniques to track down the problem - but eventually I discovered the cause.

It was the render-mode.

ServerPrerendered

What I hadn't taken the time to fully appeciate was how the ServerPrerendered worked.

From the Microsoft Docs page:

"Renders the component into static HTML and includes a marker for a Blazor server-side application. When the user-agent starts, it uses this marker to bootstrap a blazor application."

The important part here is the "Renders the component into static HTML".

On first request, the ServerPrerendered will return the the browser a static HTML representation to the page requested (with all its components). The browser will display this HTML - then run the Blazor Javascript to establish a SignalR connection. Once the SignalR connection is established THEN the Blazor page is re-rendered - this time with all the Blazor goodness.

What you are effectively getting it a two stage render to the browser:

Cosmetic render of the component - all the HTML - but none of the functionality
Functional render of the components - replaces the cosmetic only HTML with all the intended functionality

This is a techniques called hydration that has been popular in Javascript Single-Page-Apps (SPAs) for a while. The intention is to provide the user with valuable content (the HTML) while the app is downloading, initializing and starting in the background. Once ready the app would "take over" - replacing the HTML on screen.

Done right it would look to the user that the app is ready much quicker that it actually is (plus the technique provides a considerable benefit for SEO - the clawler doesn't need to execute the Javascript to understand the content).

Back to my problem

So my end-to-end tests where failing due to recieving the cosmetic-only HTML and attempting to use it BEFORE the app had rehydrated and became functional.

The test would open the website - get the HTML for the first page and click on the Next button.

But this was BEFORE the app had rehydrated - thus there was no click handler behind the Next button. Thus clicking on it did nothing.

Thus when the end-to-end test asserted that the next page had been loaded, it failed because of course none of the logic had been run.

The fix

I could have changed the render-mode (see below) but I chose to implement a loading spinner while in that pre-rehydrated state;

I felt this was best both for the user and for Selenium. The user wouldn't become frustrated by a button that did nothing and Selenium would wait until the Next button appeared.

For this I created the PreRenderLoadingMessage component:

PreRenderLoadingMessage.razor

@if (HasRendered)
{
    @ChildContent
}
else
{
    <LoadingSpinner Title="Loading ..." />
}


@code {
    [Parameter]
    public RenderFragment ChildContent { get; set; }

    private bool HasRendered { get; set; }

    protected override void OnAfterRender(bool firstRender)
    {
        if (firstRender)
        {
            HasRendered = true;
            StateHasChanged();
        }
    }
}

Then I wrapped the entire app within it:

App.razor

<PreRenderLoadingMessage>
    <Router AppAssembly="@typeof(Program).Assembly">
        <Found Context="routeData">
            <RouteView RouteData="@routeData" DefaultLayout="@typeof(MainLayout)" />
        </Found>
        <NotFound>
            <LayoutView Layout="@typeof(MainLayout)">
                <p>Sorry, there's nothing at this address.</p>
                @{ Is404 = true; }
            </LayoutView>
        </NotFound>
    </Router>
</PreRenderLoadingMessage>

Thus the first render (the prerender) shows the LoadingSpinner, then subsequent (hydrated) renders would show the @ChildContent.

This technique was taken from this Microsoft Docs page.

This approach solved my problem nicely. The end-to-end tests worked like a charm once I implemented it.

Other modes

So there are two other modes available to render-mode - Server and Static.

Static will just render static HTML - it doesn't provide any of the functionality. I've not seen a good reason to use this mode - although I do wonder if it could be used with a static site generator - something like GatsbyJs. I suspect its there for future use.

Server will operate the same as ServerPrerendered but without the static HTML version on the first page request. Rather it leaves the app content empty until the SignalR connection is established and Blazor is running fully.

The problem with Server mode was that it can take a few seconds to establish that SignalR connection and to get everything "started". I didn't want to provide an empty page to the user. I'd end up adding some form of loading message in the _host.cshtml - only to then have to remove once the Bazlor app was ready.

Thus it made much more sense to use the functionality baked into Blazor with the ServerPrerendered - and I think that the PreRenderLoadingMessage is a good way to handle that.

Building a Software Survey using Blazor - Part 3 - Components

Mark Taylor — Tue, 29 Sep 2020 07:15:48 +0000

I've decided to write a small survey site using Blazor. Part of this is an excuse to learn Blazor.

As I learn with Blazor I will blog about it as a series of articles.

This series of articles is not intended to be a training course for Blazor - rather my thought process as I go through learning to use the product.

Earlier articles in this series:

Blazor is very much based on components. This was something I was very pleased to see.

Having spent a lot of time with React, I've been quite a fan of the component structure. The MVC structure enforced by ASP.Net, while familiar, has always seems a little clunky since working with React.

So it was definitely good to see that Blazor was taking a lot of its direction from Javascript frameworks like React & Vue.

We still have a little time to wait for CSS isolation by component - but that seem to be coming soon in .Net 5. Something I'll take a look at again when released.

The basics

Creating a component is very much a first class activity within Visual Studio - simply add a new Razor Component.

This creates our sample component ready to go.

Test.razor

<h3>Test</h3>

@code {

}

And we can then pull that component into any other Razor component or page by adding <Test />

One thing to watch out for is that you components namespace will be based on the folder you create it in. Just remember to include that namespace in the apps _Imports.razor file.

Code

While the markdown is easy - it just goes into the razor file. Where to put the code I suspect will produce debate in teams for years to come.

You basically have three choices:

In the Test.razor file within the @code { } block
In a Test.razor.cs file as a partial class
In a TestBase.cs "base" class (extending ComponentBase) and then @inherits TestBase in the Test.razor

While I suspect that which version is used will be personal taste, I personally would advise picking one and trying to stick to it to avoid confusion.

Personally I favour using the @code { } block within the razor file. It keeps the code & markup in one place and easy to see - similar to how I'd do it within React.

The @code { } block may get a bit unwieldy if you have a lot of code - but that maybe an indication that your trying to do too much in your component.

For me, the @code { } block should be fairly simple with any logic being injected in.

Composition over inheritance

In early versions of the Software Survey I leaned heavily on the "base" class technique. I used it to inhert functionality for the survey pages.

You can see this in this commit version; that I have two base classes used by all of the pages:

These two bases classes provided a level of functionality for all the Survey pages - which technically worked, but definitely didn't "smell" correct.

So I refactored the functionality out of the base classes into components. The components are then composed together - which has subsequently made the code considerably easier to understand.

If possible, always favour component composition over inheritance.

ChildContent

Similar to React, Blazor supports children being passed into a component.

An example of where I've used this is in the <EnsureBeenThroughStart /> component:

EnsureBeenThroughStart.razor

@if (_valid)
{
    @ChildContent
}

@code {
    [Parameter]
    public RenderFragment ChildContent { get; set; }

    private bool _valid;

    ...
}

The component is used to ensure that the user has visited the start of the survey (if not it redirects to the start). It should avoid respondents accidentally deep linking part way through the survey.

If valid, the component shows the @ChildContent. That @ChildContent is automatically provided by Blazor as any thing defined between the <EnsureBeenThroughStart> </EnsureBeenThroughStart> tags.

As you can see below, I wrap the entire router within it.

App.razor

...

<PreRenderLoadingMessage>
    <EnsureBeenThroughStart>
        <Router AppAssembly="@typeof(Program).Assembly">
            <Found Context="routeData">
                <RouteView RouteData="@routeData" DefaultLayout="@typeof(MainLayout)" />
            </Found>
            <NotFound>
                <LayoutView Layout="@typeof(MainLayout)">
                    <p>Sorry, there's nothing at this address.</p>
                    @{ Is404 = true; }
                </LayoutView>
            </NotFound>
        </Router>
     </EnsureBeenThroughStart>
</PreRenderLoadingMessage>

...

More to learn

Components can seem a simple concept, but like many simple things, I think they will take experience to get the best from them.

I learnt that during the refactor away from the "base" classes.

I suspect overtime (and usage) patterns of usage will emerge - as they have in React. I suspect that many ideas will cross-pollinate between Blazor and Javascript frameworks.

If you've not done so already, I'd recommend reading the Microsoft Create and use ASP.NET Core Razor components page

Building a Software Survey using Blazor - Part 2 - Better State

Mark Taylor — Mon, 21 Sep 2020 15:09:51 +0000

I've decided to write a small survey site using Blazor. Part of this is an excuse to learn Blazor.

As I learn with Blazor I will blog about it is a series of articles.

This series of articles is not intended to be a training course for Blazor - rather my thought process as I go through learning to use the product.

Earlier articles in this series:

Part 1 - State

From the last article

From part 1, I used the following setup (taking advantage of the Dotnet Core Dependency Injection) to manage state:

StateService.cs - a simple service

using SoftwareSurvey.Models;
using System.Collections.Generic;
using System.Linq;

namespace SoftwareSurvey.Services
{
    public class StateService : IStateService
    {
        private readonly List<IStateObject> _stateObjects = new List<IStateObject>();

        public T GetOrNew<T>() where T : IStateObject, new()
        {
            var state = Get<T>();

            return state ?? new T();
        }

        public void Save<T>(T state) where T : IStateObject
        {
            var existingState = Get<T>();

            if (existingState != null)
            {
                _stateObjects.Remove(existingState);
            }

            _stateObjects.Add(state);
        }

        private T Get<T>() where T : IStateObject
        {
            return _stateObjects.OfType<T>().FirstOrDefault();
        }
    }
}

Demographic.cs - object to hold state

using System.ComponentModel;
using System.ComponentModel.DataAnnotations;

namespace SoftwareSurvey.Models
{
    public class Demographic: IStateObject
    {
        [Required(ErrorMessage = "Please provide company size")]
        [DisplayName("Company Size")]
        public string CompanySize { get; set; }

        [Required(ErrorMessage = "Please provide your job seniority")]
        [DisplayName("Job Seniority")]
        public string JobSeniority { get; set; }

        [DisplayName("Job Title (optional)")]
        public string JobTitle { get; set; }
    }
}

Startup.cs - setup the dependecy injection

public void ConfigureServices(IServiceCollection services)
{
  ...

  services.AddScoped<IStateService, StateService>();
}

Demographics.razor - accessing and using the state

@code {
    protected Models.Demographic Model;

    [Inject]
    protected SoftwareSurvey.Services.IStateService _stateService { get; set; }

    protected override void OnInitialized()
    {
        base.OnInitialized();
        Model = _stateService.GetOrNew<Models.Demographic>();
    }

    protected void HandleValidSubmit()
    {
        _stateService.Save(Model);

        // Do something
    }
}

The difference a day makes

While there has been quite some time since the last article, I realized quite quickly after I posted the article I could make this cleaner - and thus much simpler.

I was overcomplicated things by have a service which allowed for various types of state object. I was adding unnecessary complexity to the system because I thought I'd need it later.

So, instead I simplified it to:

SurveyResponse.cs - Parent state object

using Newtonsoft.Json;

namespace SoftwareSurvey.Models
{
    public class SurveyResponse
    {
        public SurveyResponse()
        {
            Demographic = new Demographic();

            // Other setup
        }

        [JsonProperty(PropertyName = "demographic")]
        public Demographic Demographic { get; set; }

        // Other properties
   }
}

Demographic.cs - object to hold state (unchanged)

using Newtonsoft.Json;
using System.ComponentModel;
using System.ComponentModel.DataAnnotations;

namespace SoftwareSurvey.Models
{
    public class Demographic
    {
        [Required(ErrorMessage = "Please provide company size")]
        [DisplayName("Company Size")]
        [JsonProperty(PropertyName = "companySize")]
        public string CompanySize { get; set; }

        [Required(ErrorMessage = "Please provide your job seniority")]
        [DisplayName("Job Seniority")]
        [JsonProperty(PropertyName = "jobSeniority")]
        public string JobSeniority { get; set; }

        [DisplayName("Job Title (optional)")]
        [JsonProperty(PropertyName = "jobTitle")]
        public string JobTitle { get; set; }
    }
}

Startup.cs - The dependency injection setup

services.AddScoped(x => new SurveyResponse());
services.AddTransient(provider =>
    providerGetService<SurveyResponse>().Demographic);

Demographics.razor - accessing and using the state

@code
{
    [Inject]
    private Models.Demographic Model { get; set; }
}

As summary

The main difference was that I used the dependency injection to serve up the state models directly - rather than serving up a service which would then return the state.

Thus the simplification within the Demographics.razor page - it doesn't need to have any knowledge how to get the model - its just injected directly in. Which is cleaner code anyway.

The dependency injection sets up the scoped instance of the SurveyResponse (which is ultimately what I persist) and then provides Transient access to the relevant state object.

Per page, I basically then create a state object, add to the SurveyResponse and then make available via the Dependency Injection.

With the SurveyResponse being "Scoped" it is unique per connection - the trick I learnt from the last post. The dependency setup for the "state objects" within the SurveyResponse can be Transient as it returns references to that "Scoped" instance.

To me this just made the state management that little bit cleaner.

Building a Software Survey using Blazor - Part 1 - State

Mark Taylor — Tue, 15 Sep 2020 16:08:23 +0000

I've decided to write a small survey site using Blazor. Part of this is an excuse to learn Blazor.

As I learn with Blazor I will blog about it is a series of articles.

This series of articles is not intended to be a training course for Blazor - rather my thought process as I go through learning to use the product.

Motivation

As this is the first part of the series, I wanted to just start with the why.

Why build a survey site and why Blazor.

I want to run a survey of executive attitudes to custom software development (be it inhouse or outsourced). While I'd like to believe that most business now understand the value achieved from software development - and how best to achieve that; the reality is very much different.

Many business still appear to treat software development as a "bum-on-seat" kind of role. They treat developers (and all staff) with Theory X thinking.

Thus I would like to run a survey to establish if this is correct.

While my initial thought would be to use a service like Survey Monkey for this, I found that most services seemed rather expensive for a one-off survey.

In parallel to this, I was starting to investigate Blazor. Its a technology that I've been aware of since its original demo - but I've only recently decided to spend time on it.

Thus, why not combine the two activities and use the survey as an excuse to build out a Blazor application.

Is this the best ROI?

Probably not.

My "billable" time is considerably greater than the cost of a service like Survey Monkey. But it provides me an excuse to learn a new technology - which, given its my time I'm wasting, seems a better use than watching another series on Netflix.

Is Blazor ready?

This was definitely my initial question when I started to look at Blazor.

And, at the time of writing, I'd probably say no.

It feels early version.

The development experience you would expect just isn't there yet (or I've failed to find it).

Visual Studio will report errors but the application will build and run correctly.

There doesn't seem to be any hot reloading.

The framework also seems to be missing obvious functionality for being a full featured framework - it doesn't seem to provide support for SEO until .Net 5 for example.

But is it good enough for certain application?

I'd give a guarded yes.

I'll have a better idea as I work through the Survey Site. I certainly wouldn't use for my main website yet (lack of SEO) - but for simple apps, then maybe.

Time will tell.

Blazor Server

Ok, a step back ... what is Blazor - from the Microsoft Page:

Blazor is a framework for building interactive client-side web UI with .NET:

Create rich interactive UIs using C# instead of JavaScript

Share server-side and client-side app logic written in .NET.

Render the UI as HTML and CSS for wide browser support, including mobile browsers.

Integrate with modern hosting platforms, such as Docker.

Using .NET for client-side web development offers the following advantages:

Write code in C# instead of JavaScript.

Leverage the existing .NET ecosystem of .NET libraries.

Share app logic across server and client.

Benefit from .NET's performance, reliability, and security

Stay productive with Visual Studio on Windows, Linux, and macOS.

Build on a common set of languages, frameworks, and tools that are stable, feature-rich, and easy to use.

In short - build you web pages using C# rather than JavaScript.

Blazor comes in two versions - Web Assembly and Server.

Web Assembly will download a special version of the .NET runtime to the browser and allow you to run DLLs on the browser as you would on your local machine. This is all provided by Web Assembly and gives considerable level of power - but at the cost of a sizeable download.

Server will interact with the browser of SignalR (a Microsoft abstraction over web sockets). The "work" is carried out on the server with DOM changes being sent back to the browser. This should give considerably smaller download size - but will be slightly less performant as the logic is run on the server rather than the browser.

For me, the Blazor Server version seems the appropriate way to go for this project.

Based on the Microsoft Page; Blazor Server will be supported on most browsers:

State

The survey will follow a simply structure of 4-5 pages of questions with a save to persistent storage at the end.

There is no need for authentication or to persist the respondents answers "during" the survey.

I do however need to keep track of the answers "so-far" in the survey.

Moving from ASP.Net MVC to Blazor Server requires thinking about things a little differently. And state is one of them.

Where as ASP.Net MVC you may use session state for this, Blazor Server provides some other options - storage on the browser, persistent storage on the server (database, blob storage, etc) or to use a scoped service.

And the scoped service is the choice I've gone for.

A scoped service is using the .NET Core Dependency Injection to provide the same instance of class for a users connection.

For Blazor Server, the users connection is referred to as a circuit and is basically the SignalR connection. If it gets broken, then a new circuit will be created (in this case losing the class instance).

The Microsoft Page describes it as:

Blazor Server hosting model supports the Scoped lifetime. In Blazor Server apps, a scoped service registration is scoped to the connection. For this reason, using scoped services is preferred for services that should be scoped to the current user

My StateService

With this in mind I created a simple service:

using SoftwareSurvey.Models;
using System.Collections.Generic;
using System.Linq;

namespace SoftwareSurvey.Services
{
    public class StateService : IStateService
    {
        private readonly List<IStateObject> _stateObjects = new List<IStateObject>();

        public T GetOrNew<T>() where T : IStateObject, new()
        {
            var state = Get<T>();

            return state ?? new T();
        }

        public void Save<T>(T state) where T : IStateObject
        {
            var existingState = Get<T>();

            if (existingState != null)
            {
                _stateObjects.Remove(existingState);
            }

            _stateObjects.Add(state);
        }

        private T Get<T>() where T : IStateObject
        {
            return _stateObjects.OfType<T>().FirstOrDefault();
        }
    }
}

This is a simple list of registered objects. Each "page" of the survey will have a state object which implements the IStateObject. For example:

using System.ComponentModel;
using System.ComponentModel.DataAnnotations;

namespace SoftwareSurvey.Models
{
    public class Demographic: IStateObject
    {
        [Required(ErrorMessage = "Please provide company size")]
        [DisplayName("Company Size")]
        public string CompanySize { get; set; }

        [Required(ErrorMessage = "Please provide your job seniority")]
        [DisplayName("Job Seniority")]
        public string JobSeniority { get; set; }

        [DisplayName("Job Title (optional)")]
        public string JobTitle { get; set; }
    }
}

Dependency Injection setup

The DI setup in basically the same as any .NET Core application. You add the Scoped class to the Startup.cs:

public void ConfigureServices(IServiceCollection services)
{
  ...

  services.AddScoped<IStateService, StateService>();
}

Usage

Then within the relevant Blazor component, you inject the StateService and use to get & save the state object:

@code {
    protected Models.Demographic Model;

    [Inject]
    protected SoftwareSurvey.Services.IStateService _stateService { get; set; }

    [Inject]
    protected NavigationManager NavigationManager { get; set; }

    protected override void OnInitialized()
    {
        base.OnInitialized();
        Model = _stateService.GetOrNew<Models.Demographic>();
    }

    protected void HandleValidSubmit()
    {
        _stateService.Save(Model);
        NavigationManager.NavigateTo("/ThankYou");
    }
}

The end result

This gives me an ability to store page state objects to a service (simple class) during the lifetime of the users interaction with the survey.

There would be some downsides to this approach for some applications:

The state is in memory of the server - which is fine for a quick survey
If the connection is lost, the server goes down or the browser errors then the state "so-far" will be lost. Again, I'd consider this acceptable for this use case.
The server will have an overhead for every active user of the site. This is unlikely to be a problem for this use case as I am unlikely to get high volumes of respondents at the same time (chance would be a fine thing).

On that last point, using the Azure SignalR Service would address this issue. This maybe something I look at later in the project - if nothing else than to have a go with the service.

Can see the full code for this stage of the project in Github