Task 01 - Change the application (15 minutes)

Introduction

We have a Dev Box configured, so now it is time to ensure that everything works as expected. We can do this by making a simple change to the demo application and ensuring that we are able to commit this code to GitHub from the Dev Box.

Description

Developers at Munson’s Pickles and Preserves like the Team Messaging System in general, but they consistently bring up issues with one aspect of the application: it limits messages to 200 characters or fewer. Developers have made a case that the app should support messages of up to 250 characters in length instead.

In this task, you will modify the application to support 250 characters instead of 200. You will also follow a feature branching strategy and use a pull request to bring your change into the main branch. If you wish to complete this task using a Test-Driven Design approach, please read the Advanced Challenges (optional) section below before making any changes.

Create a new GitHub Issue indicating the desired outcome.
Create a new branch in GitHub for your changes.
Fetch changes on your Dev Box and check out the new branch you have created.
Make any necessary modifications to the .NET application to change the limit on message length from 200 to 250. Be sure to update any error messages or other indicators as well so you do not have incorrect error messages or display messages. Use GitHub Copilot to assist in this development job.

When running the .NET app, you will not be able to input more characters than the message length you set (either 200 or 250 characters). If you wish to test this, you will need to try a different route in a unit test (hint). See the Advanced Challenges section for more detail.
Commit the changes to the feature branch in your GitHub repository. Ensure that your commit message includes verbiage to the extent of “Resolves #x”, where ‘x’ is the issue number for the issue you created. This will allow you to auto-close the issue once your code makes it into the main branch via pull request.
Create a pull request from your feature branch into your repository’s main branch. Be sure that your pull request is not going to the Microsoft repository you originally forked. Add another learner on your team as a reviewer for this pull request. Your code reviewer should read through the changes, comment on any issues, and approve the review if the change looks good.
After your team member reviews and approves the pull request, complete the pull request to merge the changes from your feature branch into your repository’s main branch. Delete the feature branch upon completion.

Success Criteria

You are able to run your web application on your Dev Box successfully after making changes.
You are able to insert a message of length 250.
You are not able to insert a message of length 251.
All of your changes are now in the main branch of your GitHub repository.
The issue you created for this ticket is now closed and the feature branch has been deleted.

Learning Resources

Solution

Expand this section to view the solution

To create a new GitHub Issue, select Issues from the GitHub options menu and then select the New issue button. Enter an appropriate title and comment and then choose Submit new issue to create it.
To create a new branch in GitHub, select <> Code from the GitHub options menu. Then, choose the “main” drop-down menu below the GitHub repository title and select View all branches to navigate to the branch list. Select the green New branch button and then enter your new branch name and select Create new branch to complete the process.
On the Dev Box, run git fetch from the Git bash shell to fetch the latest changes. Then, run git checkout {new branch name} to make that the working branch.
The only necessary app modification is in Application\src\RazorPagesTestSample\Data\Message.cs and involves changing line 12.
To commit the change to the repository, add the changes to the working space with a command like git add .. Then, run a command such as git commit -m "Resolves #6", assuming that 6 is the relevant issue number. Run git push to push the changes from the remote branch to GitHub.
To create a pull request in GitHub, select Pull requests from the GitHub options menu. Then, select the New pull request option. The base branch should be “main” for your repository, not the Microsoft repository and the compare branch should be the new branch you’ve created. Then, select the green Create pull request button. On the pull request form, you may add a reviewer by selecting the gear icon in the “Reviewers” section and then selecting a user from the drop-down list or typing in a username. After filling in pull request details, select the Create pull request button to create the pull request and alert the reviewer. Note that the GitHub website may prompt you to create a pull request on the main page or on the Pull requests page, and you may choose this option as a shortcut to save a couple of steps.
To review a pull request, a team member should open the pull request, either directly through the link in the e-mail GitHub sends or by navigating to the appropriate repository and choosing the pull request from the Pull requests menu. The learner should navigate to the Files changed tab and review any changes, ensuring that line 12 Message.cs now supports 250 characters instead of 200. There may also be one or more unit test updates to review. If the review is successful, the reviewer may choose the green Review changes button on the right-hand side, choose the “Approve” radio button, and then select Submit review to complete the task.

A separate team member must review the pull request. You cannot review and approve your own pull requests.
Once the team member has completed the pull request, you can open the pull request and select the green button to merge changes and complete the pull request. You may also wish to select the checkbox to delete the feature branch. Alternatively, you can return to the branches list from the <> Code menu option and delete the branch manually.

Advanced Challenges (optional)

Your code change did not affect any unit tests. In practice, this is a sign that we are missing at least one valid unit test case. As part of your code changes, introduce unit tests which test the insertion of a message of length 150, a message of length 199, a message of length 200, a message of length 201, a message of length 249, a message of length 250, a message of length 251, and a message length of 300. You may wish to do this as one parameterized test case (hint).

Another challenge is that, unlike the behavior you would expect from inserting a row into a relational database, the string length decorator does not get enforced on object creation, meaning that you could create a Message with a Text length of 400 characters and not trigger an error. You will need to validate this separately (hint).

Use GitHub Copilot to assist in creating the appropriate unit tests.

Advanced Challenge Solution

Expand this section to view the advanced challenge's solution

The solution is to use the Validator.TryValidateObject() function in System.ComponentModel.DataAnnotations to validate the object, passing in our desired string length and expected results. Add these unit tests to Application\tests\RazorPagesTestSample.Tests\UnitTests\DataAccessLayerTest.cs The code for this test case is as follows:

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

  // This picks up inside the DataAccessLayerTest class.
  [Theory]
  [InlineData(150, true)]
  [InlineData(199, true)]
  [InlineData(200, true)]
  [InlineData(201, true)]
  [InlineData(249, true)]
  [InlineData(250, true)]
  [InlineData(251, false)]
  [InlineData(300, false)]
  public async Task AddMessageAsync_TestMessageLength(int messageLength, bool expectedValidMessage)
  {
      using (var db = new AppDbContext(Utilities.TestDbContextOptions()))
      {
          // Arrange
          var recId = 10;
          var expectedMessage = new Message() { Id = recId, Text = new string('X', messageLength) };

          // Act
          var isValidMessage = Validator.TryValidateObject(expectedMessage, new ValidationContext(expectedMessage), null, validateAllProperties: true);

          // Assert
          Assert.Equal(expectedValidMessage, isValidMessage);
      }
  }