Today in this article, we shall see Visual Studio Live Share features in detail.

Recently I happened to try and use Live Share and was stunned by the power of this tool.

If I ever opt to choose the best feature or tools recently released by Microsoft, then Live Share would be my first choice undoubtedly.

Visual Studio Live Share certainly aims to do away with the traditional practice of sharing the screen via Skype, Slack, or Teams instead of the live interactive code-sharing session.

One can share a file or full project context with continuous collaboration bringing Developers, Testers, and Architects together.

This is one of the tools that can take SDLC to the next level as software industries are leaning towards more lean-agile and T-shaped teams.

As we are now aware the primary goal of Live Share is to enable developers to collaborate easily.

There are below additional use cases that Live Share is capable of addressing.

• Paired programming
• Continuous Code Review
• Interactive Learning/Session
• Technical Interviews
• + Many more

Let’s get started and follow the step-by-step process to configure live share for Visual Studio Code.

Prerequisites

• IDE – Visual Studio Code (1.22 or higher) , VS2017(15.6 and above) or VS2019
• OS – Windows (7,8 or 10) , macOS(10.12) , Linux (Ubuntu 16.04+, Fedora 27+,CenterOS7)

Getting Started – Visual Studio Live Share

Install Visual Studio Code Live Share

• Install through VS extension within VS Code.

OR Please install from Market place

• Once installed successfully Live share icon can be seen in the Status Bar and Activity Bar. Please open the project or files to use it for Live share,

Sharing Project or Files

Please click on Live Share in the Status Bar or Activity as shown above.

Users will be prompted with the below information message showing the default connection mode used will be “Auto”. Please click “OK” to proceed.

An invite link will be copied to your clipboard automatically.

Once you start your collaboration session, you can set the session to be read-only to prevent guests from making edits.

By default, it will be read-write mode will be enabled the user will be able to edit the code shared in the session.

Let’s share this link with someone who wants to collaborate. I tried sharing this link to someone who has Visual Studio 2017 or 2019 installed but not VS Code. I found it to be working perfectly fine.

Participants joining the shared link need to click on ‘Join collaboration sessions.

Participants enter the invite link within the command pallet windows below

Once connected all participants will be visible under the session details as below,

Let’s allow 1 more new participant (with VS2019) to collaborate.

Please note that the collaboration between the VSCode and VS2019 works perfectly fine.

Participants joining the same meeting invite using VS2019.

Real-time Collaboration in VSCode and VS2019

The below figure shows the real-time Live Share Collaboration in VSCode and VS2019 for the shared codebase.

Stopping the collaboration session

Stopping the sharing session can be done using the below options,

Sharing Terminal windows – Visual Studio Live Share

Apart from sharing projects or files, Live Share allows you to share your terminal window with other users. The shared terminal can be read-only (default) or read/write thereby allowing full collaboration.

Each participant can run commands on the terminal window, see the results, do Builds, run test cases.

Collaborative Debugging – Visual Studio Live Share

Visual Studio Live Share allows a team to follow a collaborative debugging technique to solve any problem/issue. Team members can use this technique for troubleshooting issues by providing a shared debugging session on the host’s machine.

Highlights of Visual Studio Live Share

Here I have listed a few nice-to-know characteristics of Live Share for your information,

• Visual Studio Live Share is SSH or SSL encrypted and authenticated.

• Live Share allows a user to share the Terminal window with each other.

• Users can perform remote debugging by sharing the locally hosted server application.

• Live Share allows you to share your active debug session, without requiring participants to install any of the necessary platforms SDKs (e.g. Node.js, Go, .NET Core) or tooling extensions.

• Live Share allows you to share debug state for any programming language or runtime environment (e.g. Kubernetes, React Native app)

• Live Share allows you to share code between different IDE like VSCode and Visual Studio is possible.

• Embedded JavaScript in HTML is supported when doing client debugging.

• JavaScript / TypeScript debugging for Node or browser is supported.

• Currently, the guest limit is up to 30 users. (Please check for any updates on limits)

• Users can join in read-only mode to avoid accidental edits.

• Live Share allows you to control sensitive file access and visibility if required.

References:

• Visual Studio IntelliCode – Code Development using AI

Do you have any comments or ideas or any better suggestions to share?

Please sound off your comments below.

Happy Coding !!

Summary

VS Live Share is undoubtedly one of the most recent features from Microsoft. Live share enables developers to collaborate easily and also eases performing extreme programming(XP) practices like paired programming, mob programming, continuous code review, performing Interactive Learnings, conducting brainstorming Sessions, etc…

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2025) best practices and guidelines for software design and development.

The post How to use Visual Studio Live Share – Paired Programming and Collaboration first appeared on TheCodeBuzz.

Today in this article we shall see how to Unit Test and Mock ActionFilter and mock ActionExecutingContext classes often useful for testing the controller logic in the API or ASP.NET Core MVC application.

You can use the below-discussed approach using the XUnit or NUnit or MSTest framework of your choice.

Unit test cases of controller-specific methods make API robust and help identify any breaking changes early.

We shall use below sample code below where the controller is attributed with filter attribute i.e ApiInputInterceptor attribute as shown below example,

The controller with action filters includes the below-listed methods. These methods wrap the filters that run for a given action,

• OnActionExecuting – runs before any of the action’s filters.
• OnActionExecuted – runs after all of the action’s filters.
• Or OnActionExecutionAsync– async format

Below is the simplified implementation of the ApiInputInterceptor for demonstration purposes,

public class ApiInputInterceptor : ActionFilterAttribute,IActionFilter
    {
   
        public override void OnActionExecuting(ActionExecutingContext context)
        {
            // do something before
            if (!context.ActionArguments.ContainsKey("Id"))
            {
                context.Result = new BadRequestObjectResult("The id must be passed as parameter");
                return;
            }
        }
        public override void OnActionExecuted(ActionExecutedContext context)
        {
            //throw new NotImplementedException();
        }
    }

Let’s now create the Unit test case for this Action filter attribute which is of type ApiInputInterceptor

Step 1- Create Mock of ActionContext

Below is a simple way of creating a mock of ActionContext. This mock object will be needed in the next steps where we will create a mock setup for ActionExecutingContext.

Below we are creating a mock object of HttpContext, RouteData, and ActionDescriptor using the moq library.

 var actContext = new ActionContext(
                Mock.Of<HttpContext>(),
                Mock.Of<RouteData>(),
                Mock.Of<ActionDescriptor>(),
                Mock.Of<ModelStateDictionary>()
            );

Step 2- Create Mock of ActionExecutingContext

Let’s now create the mock for ActionExecutingContext using the mock action context object as defined above. We are also passing a mock list of IFilterMetadata and Dictionary key-value pairs.

var actExecutingContext = new ActionExecutingContext(
                actionContext,
                new List<IFilterMetadata>(),
                new Dictionary<string, object>(),
                Mock.Of<Controller>()
            );

Step 3: Define action arguments for GET or POST method

If input arguments expect an input with the name “id” then please define it as below,

Example

 actionExecutingContext.ActionArguments["Id"] = "123";

If action arguments expect a complex type as arguments especially in case POST operation then below is a sample example on defining the complex or class object as an action argument.

Example

var source = new Source
            {
                FirstName = "ABCD",
                Address = "USA",
                Id = "1232"
            };
actionExecutingContext.ActionArguments["Id"] = source;

Let’s define the action by creating the instance of ValidateInputAttribute and executing the OnActionExecuting method

 //Act

  var valInputObject = new ApiInputInterceptor();
  valInputObject.OnActionExecuting(actionExecutingContext);

Step 4: Define Assert

We are making sure the result of validation fails reports BadRequestObjectResult as shown below,

Assert.IsType<BadRequestObjectResult>(actionExecutingContext.Result);

Useful References

• RESTFul API/Controller Unit Testing – Best Practices

Do you have any comments or ideas or any better suggestions to share?

Please sound off your comments below.

Happy Coding !!

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2025) best practices and guidelines for software design and development.

The post Unit Test and Mock ActionFilter in ASP.NET Core first appeared on TheCodeBuzz.

I’m going to talk about simple and easy-to-understand Unit Test Naming Conventions and Best Practices that can be followed while writing Unit Testing.

As we know Naming standards in any format for anything ( code, documents, unit tests, etc) are always helpful in the long run. The naming standard brings uniformity and avoids ambiguity.

Today in this article, we will cover below aspects,

Coming to Unit testing naming, however, we don’t really need to get crazy. However, by following them we get multiple benefits.

Following such naming doesn’t require any extra effort, as once put into practice, you enjoy all their benefits.

In our last article, we understood general best practices for writing the unit test cases.

However today in this article we will focus primarily on the naming conventions

Today we will see how to use the naming convention for,

• Test Method

• Test Class

• Test Project

Developer’s Confusion on Naming ??

This is a small but very common problem among developers.

There is always confusion in the Developer community on how to name and structure Unit Test cases properly.

Most often developer ends up writing their test cases without any guidelines resulting in issues like tests are not readable, not properly structured, and difficult in troubleshooting, especially on the build server where thousands of test cases run daily.

Naming Pattern for Unit Testing

As we discussed in our last article on Unit testing best practices, it’s important to understand that while writing actual unit test cases everything is drilled down to finally Classes and Functions.

These two entities are required to be unit tested in isolation for a given functionality implemented in methods.

Unit Test Project Naming Convention

The below examples are just guidelines to help you with the naming pattern for the Test project.

You are free to use your own customized naming pattern as required. Below are just few suggestions based on my experience. 😉

Pattern:

[App-Name].Unit.Tests

Example: BooksApi.Unit.Tests

Other conventions like BooksApi-Unit-Tests can also be used if found suitable.

Unit Test Files Naming Convention

Files can be named after the class names you are dealing with …

Pattern:

[ClassName]Tests

Example: BookServiceTests.cs

Tips:

• Every class with the public method (at least one method) should have a test file created. (This also means you should refactor your files as per classes)

• Make sure to write unit test cases for all public APIs for each given class.

• Each test file should be completely isolated from other files.

Unit Test Class Naming Convention

You need a test class to encapsulate all your test cases. This test class provides an entry point to test cases depending on the configuration.

This also helps to initialize the test data required for test cases.

Pattern:

[ClassName]Tests

Example: ‘EmployeesTests’ where Employee is a class name.

Tips:

• Name your Test Class as per the business class name.
• Each Test Class should be defined in a separate test file as discussed above.
• Each Test Class should have a mechanism to initialize mock or test data
• Each test class should be public.

Unit Test Method Naming Convention

Each Unit test method should be unit tested in isolation. This isolation can be simplified by a Class and all its methods.

Pattern :

[UnitOfWork]_[Method]_[Behaviour]

Example: BookService_GetBookAsync_InValidBookID_Failure

Unit Test Structure

One can follow the AAA or Given-When-Then style pattern while structuring your test cases.

Pattern:

Act – Arrange – Assert

The essential idea of the AAA pattern is to break down writing your test into three sections.

• Arrange: This describes a preconditioned state of the test before you begin to test the behavior you’re specifying in this scenario. Helps you create required test preparations, test data, mocking, etc.

• Act– This section tests the behavior that you’re specifying.

• Assert– This section describes the changes you expect due to the defined inputs through arranging and specified behavior through Act.

Some of you might like one more pattern as below,

Pattern:

Given-When-Then 

The above pattern has the same meaning on the structure as defined above for the AAA pattern.

Given-When-Then is most popular in Behavior-Driven Development (BDD) and Functional Testing.

Do you find the above conventions helpful?

References:

• Integration Testing Best Practices in Agile

• Top 10 Unit Test Best Practices in Software Development

Do you have any comments or ideas or any better suggestions to share?

Please sound off your comments below.

Happy Coding !!

Summary

In this post, we learned a few basic and easy-to-use naming conventions for Unit Testing. We looked at the different naming convention which is useful for Test Project, Test Files, Test Class, Test method and Test method structure, etc.

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2025) best practices and guidelines for software design and development.

The post Unit Test Naming Conventions Best Practices first appeared on TheCodeBuzz.

Today in this article, we shall see how to Unit Test and Mock IOptions <T> instance often used in Controller or other modules for injecting the configuration details.

Today in this article, we will cover below aspects,

The IOptions interface pattern provides access to configuration details in related classes as well as
the option to load config data depending on the situation.

The IOptions interface will be used to load the configuration as needed in the program.

Example:

public class ProducerController : ControllerBase
     {
         readonly ProducerConfigSettings _producerConfigSetting;
         public ProducerController(IOptions producerConfig)
         {
             _producerConfigSetting = producerConfig.Value;
         }

.

.
     }

The above shows ProducerController which is a controller class injecting Apsettings.json key-value pair using the IOption pattern.

For more details on IOption Pattern, please visit the below article,

• Configuration in ASP.NET Core

Unit test IOption without Mock

In this approach, you certainly need not have to mock the Apsettings object. You can send test settings details via the settings object as below and test all positive and negative scenarios as required.

Example

            //Arrange
            ProducerConfigSettings appSettings = new ProducerConfigSettings() 
            { 
                Key1 = "testkey1",
                Key2 = "Testkey2" 
            };
            IOptions<ProducerConfigSettings> options = Options.Create(appSettings);
            ProducerController controller = new ProducerController(options);

Unit Test IOption by Mock IOption

In this approach, you can mock the Apsettings object. You can send mocked settings details via the settings object as below and test all positive and negative scenarios as required.

           //Arrange
            ProducerConfigSettings appSettings = new ProducerConfigSettings()
            {
                Key1 = "testkey1",
                Key2 = "Testkey2"
            };
            var mockIOption = new Mock<IOptions<ProducerConfigSettings>>();
            // We need to set the Value of IOptions to be the SampleOptions Class
            mockIOption.Setup(ap => ap.Value).Returns(appSettings);
            ProducerController controller = new ProducerController(mockIOption.Object);

Finally, Using any of the above approaches when you run the test cases, it starts using test/mocked app settings, instead of pulling it from the actual apsettings.json file.

References:

• Configuration in ASP.NET Core

That’s all! Happy coding!

Does this help you fix your issue?

Do you have any better solutions or suggestions? Please sound off your comments below.

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2025) best practices and guidelines for software design and development.

The post Unit Test and Mock IOptions in .NET Core first appeared on TheCodeBuzz.

Trunk-based development is a prominent source code Branching Strategy that follows a set of defined principles and best practices to perform code development on a branch called ‘Trunk’ or ‘Master’ in a collaborative way.

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’ *, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.

_ Source https://trunkbaseddevelopment.com/

We will cover the below aspects in the article,

Trunk-based development is getting huge traction recently.

These recognitions are mainly due to the realization of the fact after a decade of experience and learning on the various issue of traditional VCS (Version Control system) like Merge hell, Testing failure followed by a delay in delivering a feature and then delay in testing and acceptance, etc.

Origin and Merge Hell

The code integration phase is still an important phase even in modern code development methodologies. Generally, once a feature development is over as we know of integration of the code from different developers.

This merging sometimes also depends on multiple aspects like environment, the feature is integrated, the client-specific requirement being addressed, etc.

This merging is always challenging, as it involves a huge code base merge developed over a period of time.

The integration phase is always critical to delivery.

If any issue arising at that time could affect directly the delivery of the product.

The issue could become worse with an approach of having multiple parallel repositories in a different environment dealing with code movement from one environment to another environment.

Finally, These problems are always man-made. The good thing is these problems are solvable with best practices.

There are many mechanisms for practicing lean-agile methodologies.

Trunk-based development is slowly becoming one of the methods helping with a few common issues on code merge thereby targeting speed to the market initiative.

TBD actually complements your already established lean-agile practices and the team can get value from its usage.

Trunk Based development-based branching strategies help in practicing frequent releases and delivery of features and helping to achieve speed to the market initiative.

Trunk Based Development’s main advantage is that it keeps feature/code near to the production readiness right from the kickstart of a project.

It’s important to understand that when a feature or code is near to the release Or production readiness continuously, the team gets a lot of flexibility on revisiting the features, introducing a change in a feature or updating an implementation, or making changes to code as per the requirements.

Also, the team can revisit on design and architecture of applications if needed.

The team keeps on integrating code even if the feature is not complete. The idea here is simple, issues are easy to fix when they are small.

Trunk-based development encourages small features to be integrated in an incremental way.

A known limitation in the world of waterfall dealing with legacy source code, you will typically observe one continuous build that culminates in one deployment for a bunch of features spanning over a period of time.

Which most time produces multiple issues like merge hell and bugs etc.

Is it feasible to follow the Trunk/Master Approach?

The feasibility of following the trunk-based development could be a question for most of us.

The simple answer is ‘absolutely’ it is feasible.

There are multiple benefits of using the Trunk approach as explained in the “Benefits” section below.

Feature Toggle – Inevitable

There are multiple supportive techniques useful for following Trunk based development.

The use of Feature toggles is inevitable.

Feature toggles are dependable companions of trunk development and help to achieve the Trunk approach properly.

Trunk-based development can regulate the software development process within your sprint or iteration cycle.  

Teams develop a cadence for a release-ready feature implementation which is integrated together with feature flags.

Benefits of Trunk-Based Development

• Small incremental Feature development gives greater visibility of features being developed.

• Compliment the CI-CD process with Continuous Integration and continuous deployment of code.

• Small Feature development can be aligned with lean Agile methodologies improving the velocity of the team overall.

• Code on Master/Trunk is always ready to be released due to only one Trunk.

• Reduces the cost of manual code merge (usually done in the form of the integration process of the codebase).

• It enables the team’s ability to release new features more frequently.

• Trunk methodologies with a combination of practices improve the quality of deliverables.

• Shift-left enablement.

• Cross-team collaboration with XP practices.

• Eliminates heavy code merges.

Best Practices of Trunk-Based Development

Develop the Trunk/Master

• That means one and only Master or Trunk should be used for all development.
• This is different from Git Flow where actual development happens on dedicated branch-like DEV then Test etc.
• One should always use Feature Branches for small feature development.
• Small Feature Branch should not last for more than 1-2-3 days.

Feature Branch life span a few days(1-3 days)

• Developers should develop a practice of not keeping the code to themselves.
• The code should be merged with Master within a few days, typically 1-3 days.
• Code merge should be done for what you own that day with the precondition of a successful build, and test cases passing.
• Code merge can be done even if the feature is not complete. Make sure build and test cases are passing.

Create Feature branches from the Master/Trunk

Example

• Ex, If using Git as VCS then origin/master (remote) should be used for creating a Feature branch.
• The idea here is every new development should progress using the latest available code from Master/Trunk.

Feature Branches can be Aligned with the small feature and hence user stories or task

• New Feature branches can be created for small development and can be aligned with user stories or tasks.
• If aligned with a user story or task, please make sure the Feature branch code doesn’t last long beyond 2-3 days.
• The idea here is to merge and deploy small features in logical chunks and as early as possible usually within 1-3 days.

Clean merges to Trunk/Master

• The small feature developed should be validated, and reviewed within the Feature branch itself right before the merging to Master/Trunk.
• Always sync your changes from the source control.
• Feature branch code should be reviewed before the merge to the Master/Trunk.
• Clean merges here means code that is in a Green state i.e passes build, unit test, etc.
• Do only clean merges to Trunk which are validated and reviewed

Don’t commit to Master/Trunk directly

• It’s recommended not to commit directly to the Master/Trunk branch instead one should create a Feature branch (short 1-3 days).

• It’s recommended to create a feature branch for every merge.

• Smaller teams sometimes tend to check directly to the Master which is okay for a team of 1 or 2 (if code review is followed strictly.)

Merge should be from a Feature branch to the Master/Trunk

• Merge should be unidirectional that is from a Feature branch to Master/Trunk.

• Merge from the Release branch to the Master branch can be avoided.

• Intermediate merges to master (Trunk) are not allowed.

Every merge should be production-ready

• Do a clean merge with known and agreed functionalities including limitations if any.
• Do clean merges even if the feature is not completed fully.

Merges to Trunk/Master

• Merges between one Feature branch to another Feature branch must be avoided.

• The best practice is to follow the uni-directional merge that is merge of Feature Branch to Master/Trunk should be used.

Feature branch>>>> Master/Trunk>>>>>>Release Branch

Keep Trunk/Master Green

The definition of green can be defined as below,

• Green for the compile and build.

• Green for the Feature being developed. It should work with known and agreed functionality.

• Green for the acceptable Test including unit tests or integration test cases.

• If the build fails, revert your changes back to the previous best state of code. One should create a new Feature branch for fixing build issues.

Release branch to Master branch merge should be avoided

• Merge from the release Branch to the master should be avoided. There are rare exceptions though (which I will talk about in future articles).

References

• Cherry Pick in Gi for Trunk-based Development

Summary

Trunk-based development is a prominent source code Branching Strategy that follows a set of defined principles and best practices to perform code development on a single branch called ‘Trunk’ or ‘Master’ in a collaborative way thereby minimizing the merge/integration pain.

It complements continuous integration and continuous delivery by keeping the code “ready to release” state and developing a cadence of merging small changes in an incremental way.

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2025) best practices and guidelines for software design and development.

The post Git Branching Best Practices – Trunk-Based Development first appeared on TheCodeBuzz.