Today, we’ll discuss the top 10 Benefits of Unit Testing procedures in this article.

Unit testing is a powerful method that has become well-known.

Software is broken down into its most basic functional units during unit testing, and these components are then put through a rigorous testing process.

The many advantages of unit testing will be discussed in this article, along with how it enhances the quality of software development as a whole.

We will see below benefits,

Improved Code Quality – Benefits of Unit Testing

Unit testing helps developers identify and eliminate bugs at an early stage of development.

By writing tests that target individual units of code, such as functions or methods, developers can ensure that each unit behaves correctly in isolation.

This systematic approach to testing promotes clean and modular code design, leading to improved code quality.

With each unit passing its tests, developers gain confidence in the correctness of their codebase, reducing the likelihood of introducing bugs during subsequent development phases.

Early Defect/Bug Detection

Unit testing facilitates the detection of bugs at an early stage, allowing developers to address them promptly.

By isolating and testing individual units of code, issues can be identified before they propagate into complex and interconnected parts of the system.

This early bug detection significantly reduces the debugging effort required in later stages of development and enhances the overall efficiency of the software development process.

Facilitates Refactoring and Code Maintenance

Unit testing plays a vital role in code refactoring and maintenance.

Refactoring involves restructuring code without changing its external behavior.

Unit tests provide a safety net during refactoring, ensuring that the desired functionality is maintained after modifications.

By running unit tests after each refactoring step, developers can quickly identify any unintended side effects or regression issues.

This encourages developers to refactor code fearlessly, leading to cleaner, more maintainable codebases and making it easier to accommodate changing requirements or enhancements.

Promotes Teamwork and Collaboration

Teamwork is encouraged in software development initiatives through unit testing. Individual unit testing makes it simpler for several developers to work on various system components at once.

Thanks to the current unit tests, each developer may be confident that their changes have not caused any regression problems.

Unit tests also act as living documentation, giving developers a clear grasp of the desired behavior of certain pieces of code and enhancing teamwork.

Unit Test as Code Documentation

Unit tests act as living documentation, illustrating how individual units of code should behave. By reading unit tests, developers gain insights into the expected inputs, outputs, and interactions of code components.

This documentation aspect is invaluable when new developers join a project or when revisiting code after a significant period.

Unit tests serve as executable examples, helping developers understand the codebase faster and encouraging adherence to coding standards and best practices.

Create Mock behavior – Describe and test Unexpected behavior

Mocking simplifies the setup process for unit tests by eliminating the need to configure or provision real external systems.

With mock objects or functions, developers can define the expected interactions and outputs without worrying about complex setup procedures.

This simplification accelerates the test preparation phase, reducing the overhead associated with configuring and maintaining test environments. It also makes it easier to replicate.

Controlled Test Scenarios execution

Unit testing lets you go above and beyond considering testing.

You can go to any extent by unit testing your module and making them great.

For example, Mocking empowers developers to have precise control over various test scenarios.

By creating test objects or functions, developers can define specific behaviors, responses, or inputs for the simulated dependencies.

Developers can systematically cover a wide range of test cases, ensuring comprehensive test coverage and enhancing the overall reliability of the software.

Faster Debugging and Troubleshooting

The particular location of the problem is shown when a unit test fails, making it easier for developers to identify the root cause.

Unit tests act as a safety net while debugging and troubleshooting software.

With less time spent searching through large code bases for issues, developers may more quickly and efficiently correct errors thanks to this targeted approach to debugging.

By reducing the amount of time spent on debugging, unit testing helps developers maintain the development momentum and deliver high-quality software on time.

Test-Driven Development (TDD)

Unit testing is a core practice in TDD. Developers write tests before implementing the code, using them as a guide to drive the development process and ensure test coverage.

Unit tests act as a form of regression testing, ensuring that previously implemented functionality continues to work as expected after changes or updates.

While unit testing focuses on testing individual units, it also aids integration testing. By isolating units, developers can verify that they interact correctly when combined, detecting issues early in the integration process.

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

Please sound off your comments below.

Happy Coding !!

Summary

Unit testing is an essential method in software development that provides several advantages that enhance the quality of software systems. Unit testing benefits the entire development process by enhancing the quality of the code, enabling early issue identification, accelerating debugging, assisting code refactoring, encouraging collaboration, and offering code documentation. It enables programmers to create durable, maintainable code.

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 Top 10 Benefits of Unit Testing – Awesome Code first appeared on TheCodeBuzz.

Today in this article, we will see programmatically verify that method was NOT called in Moq or method invocation is more than 1 or equal to of expected invocation times.

While performing unit test cases or functional test execution, sometimes it’s beneficial to know if particular logic or method was called or not. Especially in business-critical test cases, you may want to go crazy about how much validation you want to add to verify a scenario. This might help in addressing the quality of test cases written and provide additional validation steps.

We will use the below example where we will verify if the Logging method execution happened within the business logic or not.

Below is the sample example that we are calling Lognformation() and LogError().

So above we will verify for a valid scenario if LogError() is not called and same time Lognformation() is called 2 times.

Let’s write Unit test cases as below,

        [Fact]                 
        public void BookService_Get_ValidBookID_Success()
        {

            //Arrange
            var _mockBusiness = new Mock<IBusinessLayer>();
            var _mockLogger = new Mock<ILogger<ValuesController>>();
            int input = 12;
            int expectedloggerInvocationCount = 2;
            string expectedResult = "True";

            _mockBusiness.Setup(x => x.PerformBusiness()).Returns(true);

            //Act
            ValuesController controller = new ValuesController(_mockLogger.Object, _mockBusiness.Object);
            var result = controller.Get(input).Result as ObjectResult;

            //Assert

            Assert.Equal(HttpStatusCode.OK, (HttpStatusCode)result.StatusCode);
            Assert.Equal(expectedResult, result.Value);

            _mockLogger.Verify(x => x.Log(LogLevel.Information, 
                It.IsAny<EventId>(), 
                It.IsAny<It.IsAnyType>(), 
                It.IsAny<Exception>(), 
                (Func<It.IsAnyType, Exception, string>)It.IsAny<object>()), 
                Times.Exactly(2));
      
        }

Verify that method was NOT called in Moq

You can use XUnit with Moq mock support methods if logger methods are called Once or Twice, etc.

One can use the below code to achieve the same,

As I verified, the below code works for ASP.NET Core 3.1 or .NET 5 also,

 _mockLogger.Verify(x => x.Log(LogLevel.Error, 
                It.IsAny<EventId>(), 
                It.IsAny<It.IsAnyType>(), 
                It.IsAny<Exception>(), 
                (Func<It.IsAnyType, Exception, string>)It.IsAny<object>()), 
                Times.Exactly(0));

The above code is verifying if the LogError method was not called i.e called 0 times.

Verify that method was called 1 or ‘n’ times in Moq

The below code is validating that the LogInformation is getting called 2 times in a given method.

 _mockLogger.Verify(x => x.Log(LogLevel.Information, 
                It.IsAny<EventId>(), 
                It.IsAny<It.IsAnyType>(), 
                It.IsAny<Exception>(), 
                (Func<It.IsAnyType, Exception, string>)It.IsAny<object>()), 
                Times.Exactly(2));

This is useful when you are making sure developers don’t miss to call logging at least 2 times i.e start and at end of the method call. Very useful indeed for debugging and troubleshooting purposes in lower environments.

The above code matches with the below-overloaded Log method template,

References :

• Unit Test Naming Conventions 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 Testing – How to verify that method was not called in Moq? 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 ServiceFilter Attributes of Controllers and write better unit test cases for a controller with a service filter attribute.

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 ServiceFilter 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.
• OnActionExecutionAsync– async format

Below is the actual implementation of the ValidateInputAttribute,

Lets now create the Unit test case for this action filter attribute which of type ServiceFilter

Step 1- Create a 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 actionContext = new ActionContext(
                Mock.Of<HttpContext>(),
                Mock.Of<RouteData>(),
                Mock.Of<ActionDescriptor>(),
                Mock.Of<ModelStateDictionary>()
            );

Step 2- Create a 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 actionExecutingContext = new ActionExecutingContext(
                actionContext,
                new List<IFilterMetadata>(),
                new Dictionary<string, object>(),
                Mock.Of<Controller>()
            );

Step 3: Define the action

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

 var valInputObject = new ValidateInputAttribute <string>();
 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 ServiceFilter Attribute of Controllers first appeared on TheCodeBuzz.

Today in this article, we will cover below aspects,

Issue Description

While running Task scheduler configured jobs on the Windows server produce the below error,

“This Task requires that the user account specified has Log on as batch job rights”

Resolution

To resolve the error, please go to your machine’s local security policy.

Open Local Security Policy

To open Local Security Policy, on the Start screen, type the below command,

Command

secpol.msc 

and then press ENTER.

You can also use regular search using “Local Security Policy” in windows search,

Click on Security Settings -> User Rights Assignment

Under User Rights Assignment, please search for “Log on as a batch job”

Click on the option “Log on as a batch job”

Click on the Add User group and add the user name. You can search for the actual username based on the username or email if any.

That’s all, save your settings and you are all set to run the job with the privileges your Id has.

References:

• Schedule PowerShell Script using Windows Task Scheduler

Did I miss anything else in these resolution steps?

Did the above steps resolve your issue? 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 This task requires that the user account specified has Log on as batch job rights first appeared on TheCodeBuzz.