DEV Community: Theodore Karropoulos

[Boost]

Theodore Karropoulos — Tue, 10 Dec 2024 13:17:28 +0000

Refactoring: The Art of Crafting Cleaner, Smarter, and More Maintainable Code

Theodore Karropoulos ・ Dec 10

#csharp #cleancode #softwaredevelopment #codequality

Refactoring: The Art of Crafting Cleaner, Smarter, and More Maintainable Code

Theodore Karropoulos — Tue, 10 Dec 2024 13:16:21 +0000

Introduction

Imagine you're organizing your workspace. As you tidy up, you rearrange items to ensure everything is in its rightful place, making the space more functional and less cluttered. In software development, refactoring is the process of reorganizing code to make it cleaner, more efficient, and easier to maintain, without changing its external behavior.

Refactoring is a crucial skill for developers, helping to improve the design of existing code incrementally. In this article, I'll walk you through what refactoring is, why it matters, and some practical techniques with examples to guide you on your journey to writing better code in .NET.

What is Refactoring?

Refactoring is the process of restructuring existing code without altering its external behavior. Think of it as a way to polish your codebase, making it easier to read, extend, and maintain.

For instance, imagine you have a method that’s become a bit of a "catch-all" for various tasks. Refactoring might involve breaking it into smaller, focused methods, each responsible for a specific task.

Why Refactoring Matters

Let's return to the workspace analogy. A cluttered desk might still let you work, but you'll waste time searching for things. Similarly, messy code might function, but it slows you down when debugging or adding new features.

Here are the key benefits of refactoring:

Improved Readability: Makes the code easier to understand
Easier Maintenance: Simplifies adding or modifying features
Reduced Complexity: Breaks down large, convoluted methods into smaller, manageable parts
Bug Reduction: Improves clarity, which helps catch errors

Common Refactoring Techniques

Extract Method

This technique involves taking a fragment of code and extracting it into a separate method with a descriptive name.

Example:
Before Refactoring

public void PrintInvoice(Invoice invoice)
{
    Console.WriteLine($"Invoice ID: {invoice.Id}");
    Console.WriteLine($"Customer: {invoice.CustomerName}");
    Console.WriteLine($"Total Amount: {invoice.Amount}");
    // Logic for printing items
    foreach (var item in invoice.Items)
    {
        Console.WriteLine($"- {item.Name}: {item.Price}");
    }
}

After Refactoring

public void PrintInvoice(Invoice invoice)
{
    PrintInvoiceHeader(invoice);
    PrintInvoiceItems(invoice.Items);
}

private void PrintInvoiceHeader(Invoice invoice)
{
    Console.WriteLine($"Invoice ID: {invoice.Id}");
    Console.WriteLine($"Customer: {invoice.CustomerName}");
    Console.WriteLine($"Total Amount: {invoice.Amount}");
}

private void PrintInvoiceItems(IEnumerable<Item> items)
{
    foreach (var item in items)
    {
        Console.WriteLine($"- {item.Name}: {item.Price}");
    }
}

Move Method

If a method seems to "live" in the wrong class, moving it to the appropriate one improves cohesion.

Example:
Before Refactoring

public class Order
{
    public Customer Customer { get; set; }
    public decimal TotalAmount { get; set; }

    public string GetCustomerAddress()
    {
        return Customer.Address;
    }
}

After Refactoring

public class Customer
{
    public string Address { get; set; }

    public string GetAddress()
    {
        return Address;
    }
}

public class Order
{
    public Customer Customer { get; set; }
    public decimal TotalAmount { get; set; }
}

Replace Magic Numbers with Constants

Magic numbers can make your code cryptic. Refactor them into well-named constants.

Examples:
Before Refactoring

public decimal CalculateDiscount(decimal amount)
{
    return amount * 0.1m; // What is 0.1?
}

After Refactoring

private const decimal DiscountRate = 0.1m;

public decimal CalculateDiscount(decimal amount)
{
    return amount * DiscountRate;
}

Introduce Parameter Object

When a method has too many parameters, consider grouping them into a single object.

Example:
Before Refactoring

public void CreateOrder(string customerName, string address, List<Item> items)
{
    // Order creation logic
}

After Refactoring

public class OrderDetails
{
    public string CustomerName { get; set; }
    public string Address { get; set; }
    public List<Item> Items { get; set; }
}

public void CreateOrder(OrderDetails details)
{
    // Order creation logic
}

Tips for Effective Refactoring

Test Before and After: Ensure existing functionality remains intact.
Take Small Steps: Refactor incrementally to avoid breaking changes.
Use Descriptive Names: Name methods and variables clearly to reflect their purpose.
Automate Tests: Unit tests are crucial for validating changes.

Conclusion

Refactoring is like organizing your workspace—it takes effort upfront but pays off immensely in the long run. By applying techniques like extracting methods, moving methods, and replacing magic numbers, you make your codebase cleaner, more understandable, and easier to work with.

Start small. Refactor one piece of code at a time, and test thoroughly after each change. Over time, these small improvements will add up, transforming your codebase into a well-oiled machine.

Happy coding! 🚀

Integration Testing in .NET: A Practical Guide to Tools and Techniques

Theodore Karropoulos — Sat, 07 Sep 2024 13:56:39 +0000

Unit testing is great, but let’s face it: our apps are more than just isolated code blocks. Enter integration testing, a vital step in ensuring that the components in our system work together as intended.

Think of it as making sure that your pizza delivery app doesn’t just have a perfect "order pizza" button, but also ensures that clicking it sends that pizza to your door, hot and fresh (I know, priorities, right?) 😆 🍕 .

In this article, we'll dive into integration testing in .NET, discuss when and why it’s necessary, and explore some of the tools and techniques that make it less of a headache and more of a powerful ally in our testing toolkit 🧰 .

What Exactly is Integration Testing?

Before we jump into tools and code, let’s clarify what integration testing is. Simply put:

Unit testing checks individual pieces of your application in isolation, while integration testing ensures that different components (or systems) work well together.

For example, in an integration test, we’d verify if our service can talk to the database correctly, or if our API properly communicates with a third-party service. It’s a step up from unit tests and crucial for capturing the behavior of the "whole" system.

When to Use Integration Testing?

Here are a few scenarios where integration testing should definitely come into play:

When testing database interactions.
When verifying API calls or microservice communication.
When interacting with external services (e.g., payment gateways, authentication providers).
Anytime we have multiple layers or dependencies that need to talk to each other.

We’ll want to catch issues where one system works fine on its own, but breaks when trying to interact with others. Think of it as teamwork training for our code.

Tools for Integration Testing in .NET

.NET has a rich ecosystem when it comes to integration testing. Let’s break down some of the key tools that can help us streamline our process.

1. xUnit & NUnit

If you’ve been working with unit testing, these names should sound familiar. Both xUnit and NUnit are widely used for writing integration tests. Their simple structure and extensive community support make them perfect for getting started.

Example (xUnit):

[Fact]
public async Task Should_Save_Data_To_Database()
{
    // Arrange
    var service = new SomeService(_dbContext);

    // Act
    var result = await service.SaveDataAsync(somData);

    // Assert
    var savedData = _dbContext.SomeData.First();
    Assert.NotNull(savedData);
    Assert.Equal("Expected Value", savedData.SomeField);
}

Here, we’re testing an interaction between our service and the database to ensure the data is saved correctly.

2. Entity Framework Core In-Memory Database

While integration testing with a real database can sometimes be overkill for quick tests, using the EF Core In-Memory Database provides a simple way to simulate database interactions.

Why use it?

Super easy to set up and tear down.
Faster than working with a real database.

Example:

var options = new DbContextOptionsBuilder<ApplicationDbContext>()
    .UseInMemoryDatabase(databaseName: "TestDb")
    .Options;

using (var context = new ApplicationDbContext(options))
{
    // Act: Interact with your context here
}

3. Testcontainers for .NET

Sometimes, testing against a "real" service like a database or message broker is crucial. Testcontainers is a popular library that allows us to run Docker containers during our test run.

Example:

var testcontainersBuilder = new TestcontainersBuilder<MsSqlTestcontainer>()
    .WithDatabase(new MsSqlTestcontainerConfiguration { Password = "aVeryStrongPassword" })
    .Build();

await testcontainersBuilder.StartAsync();

using (var connection = new SqlConnection(testcontainersBuilder.ConnectionString))
{
    // Integration testing against SQL Server
}

Testcontainers is perfect when we need the real deal but don’t want to mess up our production database (we’ve all been there) 🧨 🔥 .

4. WireMock.Net

When we need to mock external APIs, WireMock.Net is a powerful tool that allows us to simulate HTTP interactions.

Example:

var server = WireMockServer.Start();

server.Given(Request.Create().WithPath("/api/data").UsingGet())
    .RespondWith(Response.Create().WithBody("Mocked data"));

var response = await httpClient.GetStringAsync("/api/data");

Assert.Equal("Mocked data", response);

This is especially useful when we don’t want to hit real endpoints during testing, or when the service is external.

5. Moq for Dependency Mocks

Finally, while it’s more common in unit testing, Moq can still play a role in integration tests by mocking certain services or dependencies.

Example:

var mockService = new Mock<ISomeDependencyService>();
mockService.Setup(s => s.GetData()).ReturnsAsync(mockData);

// Inject the mock into your service and run your test.

Best Practices for Integration Testing

Now that we’ve gone over the tools, let’s discuss some best practices:

Keep tests focused: Integration tests can become slow if they cover too much ground. Test one interaction at a time.
Use test databases or containers: Don’t run integration tests against your actual production services. Use Docker containers or in-memory databases to keep your environment clean.
Teardown properly: Make sure any services you start (databases, mocks, etc.) are properly stopped after the test run to avoid issues.

Conclusion

Integration testing is a critical step in building robust .NET applications. By using the right tools and keeping best practices in mind, we can ensure that our systems talk to each other the way they’re supposed to. Whether we’re testing APIs, databases, or third-party services, integration tests can save us from nasty surprises in production.

If you enjoyed my article and are interested feel free to share it in!

Happy coding 🚀 and may your integration tests be fast, clean, and reliable! 💻

Streamlining Your Tests with IClassFixture in xUnit

Theodore Karropoulos — Tue, 20 Aug 2024 11:19:04 +0000

Introduction

Imagine you’re hosting a dinner party. To make the evening run smoothly, you prepare some dishes ahead of time, like marinating the meat or baking the bread. Instead of repeating these tasks for each guest, you set everything up once and then use your prepared dishes throughout the evening. In software testing, IClassFixture in xUnit is like your pre-prepared dishes, it allows you to set up shared resources just once so you can serve them to multiple tests without extra effort.

In this article, I’ll try to explain what IClassFixture is, why it’s a valuable tool in our testing process, and how to use it effectively in your .NET projects. So, let’s get cooking! 🍲

What is IClassFixture?

When we're writing unit tests, we might need to share some setup code across multiple tests, similar to how we’d prepare certain ingredients ahead of time when hosting a dinner. Maybe there is a need to establish a database connection, configure some settings, or set up a mock service.

Instead of repeating these tasks for every test, we can use IClassFixture to keep our setup code organized and reusable.

Think of IClassFixture as the pre-prepared ingredients, it allows us to handle the heavy lifting just once and then reuse the setup across our tests.

This saves time, ensures consistency, and keeps our testing “kitchen” clean and tidy. 🧑‍🍳

Why is IClassFixture Important?

Using IClassFixture is like preparing a big meal efficiently:

Efficiency: By sharing setup code we save time and effort, just like preparing a large pot of soup that can serve many guests.
Consistency: It ensures that all our tests have access to the same setup which makes them more reliable. We do not want one of our guests to get undercooked food while others get the perfect dish! 🍲
Simplification: Our test code stays clean and organized just like keeping our kitchen organized while cooking for a big event.

Getting Started with IClassFixture in .NET

Let's jump into a practical example because nothing whets our appetite like seeing some code in action!

- Setting up a Shared Context
Imagine we have a class that manages database connections and we want to make sure this connection is established before running any tests that interact with the database.

First we'll create a DatabaseFixture class that sets up the database connection:

public class DatabaseFixture : IDisposable
{
    public DatabaseFixture()
    {
        // Initialize the database connection
        Console.WriteLine("Setting up database connection...");
    }

    public void Dispose()
    {
        // Cleanup the database connection
        Console.WriteLine("Tearing down database connection...");
    }
}

Here the DatabaseFixture class initializes a database connection in its constructor and cleans it up in the Dispose method, just like cleaning up the kitchen after the party 🍴 🥳

- Implementing IClassFixture

Next we'll use IClassFixture in our test class to tell xUnit that we're working with the DatabaseFixture:

public class DatabaseTests : IClassFixture<DatabaseFixture>
{
    private readonly DatabaseFixture _fixture;

    public DatabaseTests(DatabaseFixture fixture)
    {
        _fixture = fixture;
    }

    [Fact]
    public void TestDatabaseConnection()
    {
        // Use the shared fixture to interact with the database
        Console.WriteLine("Running a test that requires a database connection.");
        Assert.True(true); // Replace with actual test logic
    }
}

Let's break it down:

IClassFixture: This tells xUnit that the DatabaseTests class depends on DatabaseFixture for setup and teardown.
Constructor Injection: The fixture is passed into the test class's constructor giving us access to the shared setup throughout our tests. It's like having our pre-prepared ingredients ready to go when we start cooking our meal. 🥘

Practical Example: Testing a Dinner Party Service

Let’s apply the concept of IClassFixture to a scenario where we’re managing a dinner party. Imagine you have a service that handles the different courses of the meal, and you want to test this service while ensuring that the kitchen setup (like pre-heating the oven or setting the table) is done only once.

Setting Up the Kitchen: The Fixture Class

public class KitchenFixture : IDisposable
{
    public IServiceProvider? Services { get; private set; }

    public KitchenFixture()
    {
        var serviceCollection = new ServiceCollection();

        // In a typical scenario, the dependencies needed for the test 
        // would come from the application's DI container rather than 
        // being set up directly within the fixture,
        // but let's keep it simple for now
        Services = serviceCollection
            .AddScoped<IDinnerPartyService, DinnerPartyService>()
            .BuildServiceProvider();

        // Set up the kitchen, preheat the oven, etc.
        Console.WriteLine("Kitchen is ready!");
    }

    public void Dispose()
    {
        // Clean up after the dinner party
        Console.WriteLine("Kitchen cleanup complete!");
    }
}

What's happening here?

Service Setup: The KitchenFixture setups up a DI container and registers the DinnerPartyService. This is like stocking your kitchen with ingredients before the party.
Cleanup: The Dispose method is called after all tests have run, ensuring the kitchen is cleaned up and ready for the next use.

Testing the Dinner Party: The Test Class

Next we'll write our test class that uses the KitchenFixture:

public class DinnerPartyServiceTests : IClassFixture<KitchenFixture>
{
    private readonly IDinnerPartyService _dinnerPartyService;

    public DinnerPartyServiceTests(KitchenFixture fixture)
    {
        _dinnerPartyService = fixture.Services
                .GetRequiredService<IDinnerPartyService>();
    }

    [Fact]
    public void ServeAppetizer_ReturnsCorrectDish()
    {
        // Act
        string dish = _dinnerPartyService.ServeAppetizer();

        // Assert
        Assert.Equal("Bruschetta", dish);
    }

    [Fact]
    public void ServeMainCourse_ReturnsCorrectDish()
    {
        // Act
        string dish = _dinnerPartyService.ServeMainCourse();

        // Assert
        Assert.Equal("Lasagna", dish);
    }
}

There's a lot happening here, so let's simplify it step by step:

Fixture Injection: The DinnerPartyServiceTests class receives the KitchenFixture via its constructor. This is like a chef arriving at a kitchen that's already set up and ready to go.
Dependency Resolution: The test methods use the DinnerPartyService which is retrieved from the fixture's DI container. This is like a chef using the pre-prepared ingredients and tools in the kitchen. This ensures that each test uses the same service instance keeping things consistent.
Testing Dishes: The ServeAppetizer_ReturnsCorrectDish and ServeMainCourse_ReturnsCorrectDish methods ensure that the DinnerPartyService serves the correct dishes.

When to Use IClassFixture

IClassFixture is perfect for scenarios where we need to share setup logic across multiple tests, like:

Database Testing: Avoid setting up and tearing down the database connection for each test. You wouldn't want to prepare the same ingredients over and over right? 🥗
External Service Integration: Initialize a connection or mock server just once, saving ourselves from repeating the same setup every time we serve a new "dish". 😉
Configuration Setup: When tests need specific configuration settings or environment variables, IClassFixture ensures everything is set up just right, like adjusting the oven temperature before baking. 🍞

Techniques for Effective use of `IClassFixture`

Leverage Dependency Injection for Fixture Setup: Use Dependency Injection (DI) within your fixture to manage dependencies and provide them to your test classes.
Avoid Test-Specific Logic in Fixtures: Keep test-specific logic out of your fixtures. The fixture should only handle setup and teardown, not the specifics of individual test cases.
Implement Cleanup Logic: Implement the IDisposable interface in your fixture class to clean up resources properly. This way, our setup doesn't linger like dirty dishes in the sink! 🍽️

Conclusion

IClassFixture in xUnit is like pre-prepping your ingredients for a dinner party, it allows us to share setup and teardown logic across multiple tests, making our code more efficient, consistent, and easier to maintain.

By using IClassFixture, we’re ensuring that our tests are well-prepared, just like having all our ingredients ready before we start cooking. Whether we’re setting up a database connection, configuring an external service, or handling complex initialization logic, IClassFixture is a powerful tool in our testing toolkit.

So go ahead, start incorporating IClassFixture into your .NET projects, and you’ll be well on your way to serving up robust, reliable applications—just like a perfectly executed dinner party! 🍷

I hope I haven't overwhelmed you and that I've managed to clarify what IClassFixture is and how we can use it in our tests to make our lives a bit easier. If you enjoyed my article, feel free to share it with others so we can make another developer a bit happier! 🍻

Happy coding, and may your tests always “taste” just right! 🎉

Unit Testing in .NET: Tools and Techniques

Theodore Karropoulos — Sun, 11 Aug 2024 12:50:38 +0000

Introduction

Imagine you are building a LEGO structure. As you add more pieces you want to make sure each new piece fits perfectly without compromising the entire structure. In software development unit testing is like checking each LEGO piece before adding it to ensure the whole structure remains strong.

Unit testing is a fundamental practice that help us to ensure that each part of our code works correctly. In this article I will try to explain what unit testing is, why it is important and how we can perform unit testing in .NET using simple tools and techniques.

What is Unit testing?

Unit testing involves testing individual units of code like functions or methods to verify that they perform as expected. Think of a unit test as a small, automated checklist that confirms whether a specific part of your program works correctly.

For example, if you have a method that calculates the division of two numbers, a unit test would check if the method returns the correct result when given specific inputs.

Why is Unit Testing Important?

Lets shift our analogy and please imagine we are building a car. We have to test individual components like the engine, brakes, lights and so on to ensure they function properly on their own. Unit testing serves a similar purpose in software development.

There are several reasons why this is important, but the most significant are:

Catching bugs early, Much like identifying a faulty car component early on, unit testing helps us detect errors in our code before they escalate into more significant issues
Easier maintenance, As we keep adding or changing features in our application unit tests ensure that new changes don't break existing functionality
Confidence in code, Unit tests give us confidence that our code works as intended, making it easier to refactor and extend our application

Getting Started with Unit Testing in .NET

Enough with the theory and lets take a look in a practical example, after all it's well known that we developers prefer code over the theory that comes with it 😁

For my tests I will use the xUnit framework.

Setting up a Unit Test Project In .NET, setting up unit testing is straightforward. When we create a new project in our favorite IDE, we can add a unit test project alongside it.
- Create a new project, In our IDE we select to Create a new project and the we have to choose the desirable framework "xUnit" or "NUnit", at the moment these are the most popular testing frameworks in .NET.
- Add a reference, Ensure that unit test project references the project containing the code you want to test.
Writing our first Unit Test Let's say we have a simple method in our code that divides two numbers

public class Calculator
{
    public int Div(int numerator, int denominator)
    {
        return numerator / denominator;
    }
}

To test this method we will write a unit test like the following:

public class CalculatorTests
{
    [Fact]
    public void Div_ReturnsCorrectResult()
    {
        // Arrange
        Calculator calculator = new Calculator();

        int numerator = 10;
        int denominator = 2;

        // Act
        int result = calculator.Div(numerator, denominator);

        // Assert
        Assert.Equal(5, result);
    }
}

Lets break it down into pieces so we can better understand it:

First of all, as you can easily see, I have deliberately divided the test into three parts: Arrange, Act, and Assert. The reason for this is that it is considered good practice in our tests to use the AAA pattern. This way, we keep our tests better organized, making them easier to read and understand.

Arrange, in this section we prepare any objects or data needed for the test, like creating an instance of the calculator object or assign values to the numerator and denominator variables
Act, here we are calling the method that we want to test, Div in our case
Assert, we check if the result is what we expected, in our case if 10 / 2 should equal 5

Testing Multiple Inputs

In the example above, we created our test and ran it with a single set of inputs. But how can we run the test again using a different set of inputs? .NET testing frameworks offer a way to accomplish this without having to rewrite the entire test.

Example with the use of xUnit

[Theory]
[InlineData(10, 2, 5)]     // Test case: 10 / 2 = 5
[InlineData(20, 4, 5)]     // Test case: 20 / 4 = 5
[InlineData(0, 1, 0)]      // Test case: 0 / 1 = 0
[InlineData(-10, -2, 5)]   // Test case: -10 / -2 = 5
public void Div_ReturnsCorrectResult(
    int numerator,
    int denominator,
    int expected)
    {
        // Arrange
        Calculator calculator = new Calculator();

        // Act
        int result = calculator.Div(numerator, denominator);

        // Assert
        Assert.Equal(expected, result);
    }

Here we are using [Theory] and [InlineData] instead of the [Fact] for parameterized tests. Each [InlineData] attribute provides a different set of inputs to the test method

Similarly in NUnit we can run tests with multiple inputs by using the [TestCase] attribute

[TestCase(10, 2, 5)]     // Test case: 10 / 2 = 5
[TestCase(20, 4, 5)]     // Test case: 20 / 4 = 5
[TestCase(0, 1, 0)]      // Test case: 0 / 1 = 0
[TestCase(-10, -2, 5)]   // Test case: -10 / -2 = 5
public void Div_ReturnsCorrectResult(
    int numerator,
    int denominator,
    int expected)
    {
        // Arrange
        Calculator calculator = new Calculator();

        // Act
        int result = calculator.Div(numerator, denominator);

        // Assert
        Assert.AreEqual(expected, result);
    }

Techniques for Effective Unit Testing

Test-Driven Development (TDD)
Think of designing a car where you first create a detailed blueprint before starting the assembly. In Test-Driven Development, we write the unit tests before developing the actual code. This approach ensures that our code is built according to the specifications set by the tests, leading to a more reliable and testable software.
Mocking Dependencies
Sometimes, a method we want to test depends on external resources, like needing a specific part that’s not yet available when building our car. In these situations, we can use mocking to create a simulated version of the required component. This allow us to test our car’s assembly process without relying on the actual, unavailable part.

For example, if a method retrieves data from a database, we can "mock" the database to return a specific value without actually querying the real database.

Libraries like Moq or NSubstitute are popular choices for mocking in .NET.
Testing Both Happy and Sad Paths
When testing our code it is important to check not only the ideal scenarios (happy paths) but also how our code behaves under less that ideal conditions (sad paths).
- Happy Path Testing: This is like making sure that all the pieces fit perfectly when you follow the instructions step by step. We always want to verify that our code works as expected when everything goes right. For example, if our method is supposed to divide two numbers we write a test to ensure it returns the correct result.
- Sad Path Testing: In our example, we create a test method that examines the Div method, assuming the inputs are always valid. However, what happens if the denominator is zero? Sad path testing ensures that our code does not crash in such scenarios and either manages the error gracefully or provides a meaningful error message.
Here is an example on how we might test it:
```
[Fact]
public void Div_DivideByZero_ThrowsDivideByZeroException()
{
    // Arrange
    Calculator calculator = new Calculator();

    // Act & Assert
    Assert.Throws<DivideByZeroException>(() => calculator.Div(10, 0));
}
```
Testing both paths ensures that our code is robust and can handle real world scenarios where users may not always follow the “happy path.”
Writing Clean and Maintainable Tests
- Keep Tests Simple: Each test should focus on one thing. Think of it as testing one car component at a time.
- Name Tests Clearly: Use descriptive names so that anyone reading your tests can easily understand what they do. For example, Div_ReturnsCorrectResult clearly indicates that the test checks whether the Div method returns the correct result.
- Avoid Duplicating Code: If multiple tests require the same setup, consider using helper methods or a test setup method to avoid duplicating code.

Conclusion

Unit testing in .NET is like building a LEGO structure piece by piece, ensuring each part fits perfectly before moving on to the next. By catching bugs early, simplifying maintenance, and boosting confidence in our code, unit testing becomes an invaluable tool in our development process.

Remember to test both the happy and sad paths. While happy path testing confirms that our application works under ideal conditions, sad path testing checks its resilience and ability to handle unexpected scenarios. Together, they ensure that our application is robust, secure, and ready for real-world use.

Start small, use the tools available in .NET like xUnit or NUnit, and incorporate best practices like TDD, mocking, and comprehensive path testing. With these techniques, you'll be well on your way to building robust, reliable applications that stand the test of time—just like a well-built LEGO masterpiece 😃

If you enjoyed my article and are interested feel free to share it in. If you want to read more about Unit testing you can visit this link.

Happy coding! 🚀💻

The Differences Between EntityFramework .Add and .AddAsync

Theodore Karropoulos — Wed, 03 Jul 2024 15:25:01 +0000

Introduction

Entity Framework is a popular Object-Relational Mapper (ORM) for .NET, which allow us to better interact with a database using .NET objects. One of the fundamental operations we are using all of us that interact with databases is adding new entities. In this article I will try to explain the two methods that we have in our disposal for entities creation Add and AddAsync. We will explore their usage, differences and best practices for when to use each other.

What is `DbSet<TEntity>.Add`?

The DbSet.Add method is a synchronous method used to add a new entity to the context, which is then tracked by EF Core. When SaveChanges is called, EF Core generates the necessary SQL statements to insert the new entity into the database.
Lets see a usage example of Add method

public Task AddNewEntityAsync(Entity entity, CancellationToken ct)
{
    using (var context = new ApplicationDbContext())
    {
        context.Entities.Add(entity);
        await context.SaveChangesAsync(ct);
    }
}

How the above example works,

The Add method attaches the entity to the context with an Added state
When SaveChangesAsync is called the context creates an INSERT SQL command to add the entity to the database asynchronously

What is `DbSet<TEntity>.AddAsync`?

The AddAsync method is the asynchronous counterpart of the Add method. It is used to add a new entity to the context asynchronously. A usage example of AddAsync is given bellow

public async Task AddAsync(Entity entity)
{
    using (var context = new ApplicationDbContext())
    {
        await context.Entities.AddAsync(entity);
        await context.SaveChangesAsync();
    }
}

How it works
The AddAsync method attaches the entity to the context with an Added state asynchronously

When SaveChangesAsync is called, the context creates an INSERT SQL command to add the entity to the database asynchronously

Key Differences Between `Add` and `AddAsync`

Now the first question that pops in our minds is ok, so I will use Add when I am in a synchronous context and AddAsync when I am in asynchronous.
This is just one aspect; the other is how Add and AddAsync interact with the database.
As Microsoft explains

This method is async only to allow special value generators, such as the one used by 'Microsoft.EntityFrameworkCore.Metadata.SqlServerValueGenerationStrategy.SequenceHiLo', to access the database asynchronously. For all other cases the non async method should be used.

That simple means that event though Add and AddAsync are doing the same thing, AddAsync comes with a little overhead and that is an extra interaction with the database, something that is avoided with the use of Add

If you found my article useful, feel free to share it. Also, leave a comment if something is not clear enough.

Exploring C# Custom Types: Understanding Records, Structs, and Classes

Theodore Karropoulos — Sat, 18 May 2024 13:59:41 +0000

Introduction

As developers, we daily encounter the need to organize and manage data in our applications. Whether we are modeling complex entities, representing simple data structures, or ensuring data immutability, choosing the right construct is crucial. C# provides three primary user-defined types to help us with these tasks, classes, structs, and records. Each of these types has its unique characteristics and use cases, allowing us to tailor our approach to the specific needs of our code.

What is a class?

A class is a blueprint for creating objects. It defines a type that can have fields, properties, methods. Classes are reference types and they are stored on the heap memory and their variables hold references to the actual data. Lets better look an example on how we are using a class.

Example

// Definition
public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }

    public void Log()
    {
        Console.WriteLine($"Hello, my name is {FirstName} {LastName}");
    }
}

// Usage
Person person = new Person { FirstName = "Jane", LastName = "Smith" };
person.Log();

What is a Struct?

A struct is a value type and their storage depends on the context in which they are used. While structs are often associated with the stack, they are not always stored there. When we declare a struct as a local variable within a method, it is typically stored on the stack, for example

void SomeMethod()
{
    Point point = new Point(5, 10); // point here is stored on the stack

When a struct is a field of a class, it is stored on the heap along with the containing class instance, for example

public class SomeClass
{
    public Point point; // point is stored on the heap with the SomeClass instance
}

SomeClass someClassInstance = new SomeClass();

When structs are elements of an array, the array itself is an object on the heap, so the structs are stored on the heap, for example

Point[] points = new Point[10]; // points array and its elements are stored on the heap

Structs are typically used for small and simple objects and used to represent single values. Like classes structs may also have
fields, properties and methods. The main difference between and a struct is that a struct do not support inheritance. Lets give an example on how we can use a struct type.

Example

// Definition
public struct Point
{
    public int X { get; set; }
    public int Y { get; set; }

    public void Print()
    {
        Console.WriteLine($"Point at ({X}, {Y})");
    }
}

// Usage
Point point = new Point { X = 5, Y = 10 };
point.Print();

What is a Record?

Records are a new type introduced in C# 9.0, designed to simplify working with immutable data. Like classes, records are reference types, but they come with built-in support for value-based equality and immutability, making them a powerful tool for managing data in a clean and intuitive way.

Example

// Definition
public record Person
{
    public string FirstName { get; init; }
    public string LastName { get; init; }

    public void Log()
    {
        Console.WriteLine($"Hello, my name is {FirstName} {LastName}.");
    }
}

// Usage
var person = new Person { FirstName = "Jane", LastName = "Smith" };
person.Log();

When to Use Each

Class, use when you need a complex object that might require inheritance, mutable state or shared references
Struct, use for small and simple objects that represent single values, especially when performance is critical
Records, use them when you need an immutable object that is primarily defined by its data. Ideal for DTO (data transfer objects)

Comparing Class, Struct, and Record

Feature	Class	Struct	Record
Type	Reference	Value	Reference
Storage	Heap	Stack	Heap
Inheritance	Yes	No	Yes
Immutability	Mutable by default	Mutable by default	Immutable by default
Equality	Reference-based	Value-based	Value-based
Usage	Complex objects	Small data structures	Immutable data structures

Understanding IQueryable in C#

Theodore Karropoulos — Sat, 20 Apr 2024 18:14:55 +0000

Introduction

As developers, we often find ourselves tasked with fetching data from a database and storing it in our code for later use. The most common approach, or at least the one I've frequently encountered, is to store this data in IEnumerables.
In this article, we'll explore alternative methods for storing data using the IQueryable interface.

But first, let's understand what IQueryable is. To better understand this lets imagine we have a recipe book (which represents a data source) with many recipes (data items). Each recipe contains a list of ingredients and instructions. IQueryable is like having a set of tabs or bookmarks in our recipe book and instead of reading through the entire book we can open to a specific section (query) based on our needs. When compared, IEnumerable resembles reading a recipe book from beginning to end.

What is IQueryable

IQueryable is an interface in the .NET framework that represents a queryable collection of data. It inherits from the IEnumerable<T> interface and extends its functionality by providing support for composing and executing queries against data sources.
In simpler terms, IQueryable is like a smart container for data that allows you to ask questions about the data in a structured way. You can build complex questions by adding smaller questions together, and when you're ready, you can ask the container to find the answers for you from a specific data source.

When to use IQuearyable

Now that we know what IQueryable is, let's see in which cases it is beneficial to use it.
IQueryable is well-suited for situations where data retrieval from a source is required, such as when interacting with databases, particularly with ORM frameworks, or when querying data from remote sources like web services or APIs. Moreover, IQueryable is beneficial when dealing with large datasets, as it enables the utilization of query providers that optimize query execution and minimize memory usage by processing data in a streaming manner, rather than loading the entire dataset into memory.

Differences between IQueryable and IEnumerable

Okay, you might now ask, 'Well, why should I prefer IQueryable over IEnumerable?' Before we answer that, let's take a look at the fundamental differences between the two.

Deferred Execution

IQueryable: Supports deferred execution of queries, meaning that query operations are not executed immediately when defined but are instead executed when the results are actually needed. This allows for query optimization and composition.
IEnumerable: Does not support deferred execution. Query operations are executed immediately when invoked, resulting in all elements of the collection being enumerated at once.

Query Composition

IQueryable: Allows for dynamic composition of queries using LINQ operators. Query operators can be chained together to build complex queries, and the entire query is translated and executed at once.
IEnumerable: Supports only sequential enumeration of elements. Query operations cannot be dynamically composed, and each operation is applied separately to the entire collection.

Supported Query Operators

IQueryable: Supports a rich set of query operators provided by LINQ, including filtering (Where), sorting (OrderBy), projection (Select), grouping (GroupBy), and joining (Join).
IEnumerable: Supports a limited set of query operators, primarily those provided by the Enumerable class.

In general, we can say that IQueryable is suitable for scenarios where we need to query data from external data sources and perform dynamic, composable queries with deferred execution and query optimization. IEnumerable, on the other hand, is better suited for querying in-memory collections and performing simple, immediate operations on the data.

Mastering Resource Management in C# with the Disposable Pattern

Theodore Karropoulos — Mon, 12 Feb 2024 20:41:38 +0000

Today, we're delving into the realm of resource management in C#. We'll be exploring the Disposable Pattern and its potential to enhance your code. Get ready for an enlightening journey ahead!

Understanding the Disposable Pattern:

Picture this: You're knee-deep in coding a slick C# app, and it's crunch time. Your app's handling files, database connections, and other resources like a champ. But then, boom! 💥 You're blindsided by memory leaks and resource hogging! Oh no! 😱

Enter the Disposable Pattern. It's like having a trusty sidekick that helps you manage precious resources with finesse. At its core, the Disposable Pattern ensures that resources are properly released and cleaned up when they're no longer needed, preventing memory leaks and keeping your app running smoothly.

How Does It Work?

Think of the Disposable Pattern as a protocol for your objects. When an object implements IDisposable, it's essentially saying, "Hey, I've got resources to clean up when I'm done, so don't forget about me!"

Here's a quick breakdown of how it works:

Implement IDisposable:
- Your class implements the IDisposable interface, signaling that it has resources to dispose of.
Define Cleanup Logic:
- You define cleanup logic within the Dispose() method of your class. This could involve closing file handles, releasing database connections, or any other resource cleanup tasks.
Dispose() Method:
- When you're done with an object, you call its Dispose() method. This triggers the cleanup logic, ensuring that resources are released promptly. #### Let's Get Practical: Enough theory, let's dive into some code examples to see the Disposable Pattern in action!

using System;

public class ResourceHandler : IDisposable
{
    private bool _disposed = false;
    private MyResource _resource; // Example resource

    // Constructor
    public ResourceHandler()
    {
        // Acquire resource (e.g., file handle, database connection)
        _resource = AcquireResource();
    }

    // Dispose method
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    // Cleanup logic
    protected virtual void Dispose(bool disposing)
    {
        if (!_disposed)
        {
            if (disposing)
            {
                // Dispose managed resources
                ReleaseResource(_resource); // Release the resource
            }

            // Dispose unmanaged resources
            _disposed = true;
        }
    }

    // Custom cleanup logic for unmanaged resources
    ~ResourceHandler()
    {
        Dispose(false);
    }

    // Example method to acquire resource
    private MyResource AcquireResource()
    {
        // Acquire resource logic...
        Console.WriteLine("Resource acquired.");
        return MyResource.Instance; // Placeholder
    }

    // Example method to release resource
    private void ReleaseResource(MyResource resource)
    {
        // Release resource logic...
        Console.WriteLine("Resource released.");
    }
}

class Program
{
    static void Main(string[] args)
    {
        // Using statement ensures proper cleanup even in case of exceptions
        using (var resourceHandler = new ResourceHandler())
        {
            // Do something with resourceHandler...
            Console.WriteLine("Using resourceHandler...");
        } // Dispose() is automatically called here
    }
}

Conclusion:

And there you have it! The Disposable Pattern is your secret weapon for managing resources like a pro in C#. By implementing IDisposable and following the pattern, you can ensure that your precious resources are cleaned up properly, preventing memory leaks and keeping your application running smoothly.

So go ahead, unleash the power of the Disposable Pattern in your code, and say goodbye to resource management woes once and for all! Happy coding! 🚀

Extract Method Refactoring

Theodore Karropoulos — Thu, 07 Dec 2023 17:40:53 +0000

Extract Method

The Extract Method refactoring technique involves breaking down a section of code into a separate, named method. This technique is beneficial for improving code readability, promoting code reuse, and making the codebase more maintainable.

Simple Explanation:

Imagine you have a block of code that performs a specific task within a method. Instead of keeping all that code in one place, you can extract it into a separate method with a meaningful name. This is the Extract Method refactoring.

Example of Extract Method (Before):

Now for us to better understand this technic lets consider a method that calculates the total price of items in a shopping cart. Initially, our code might look like this:

public class ShoppingCart
{
    private List<Item> items;

    // ... other methods ...

    public decimal CalculateTotalPrice()
    {
        decimal totalPrice = 0;

        foreach (var item in items)
        {
            // Complex logic for calculating item price
            decimal itemPrice = item.Price * item.Quantity;

            // Additional logic, perhaps applying discounts or taxes
            itemPrice = ApplyDiscounts(itemPrice);
            itemPrice = ApplyTaxes(itemPrice);

            totalPrice += itemPrice;
        }

        return totalPrice;
    }

    private decimal ApplyDiscounts(decimal price)
    {
        // Complex logic for applying discounts
        // ...

        return price;
    }

    private decimal ApplyTaxes(decimal price)
    {
        // Complex logic for applying taxes
        // ...

        return price;
    }
}

Refactored Code using "Extract Method" (After):

As you can easily observe, the logic within the foreach loop appears extensive, making it challenging for someone to quickly grasp its purpose. To enhance clarity, we will refactor this by extracting the logic responsible for calculating the price of an individual item into a distinct method.

public class ShoppingCart
{
    private List<Item> items;

    // ... other methods ...

    public decimal CalculateTotalPrice()
    {
        decimal totalPrice = 0;

        foreach (var item in items)
        {
            // Extracted method for calculating item price
            decimal itemPrice = CalculateItemPrice(item);

            totalPrice += itemPrice;
        }

        return totalPrice;
    }

    private decimal CalculateItemPrice(Item item)
    {
        // Complex logic for calculating item price
        decimal itemPrice = item.Price * item.Quantity;

        // Additional logic, perhaps applying discounts or taxes
        itemPrice = ApplyDiscounts(itemPrice);
        itemPrice = ApplyTaxes(itemPrice);

        return itemPrice;
    }

    private decimal ApplyDiscounts(decimal price)
    {
        // Complex logic for applying discounts
        // ...

        return price;
    }

    private decimal ApplyTaxes(decimal price)
    {
        // Complex logic for applying taxes
        // ...

        return price;
    }
}

In the refactored code, the logic for calculating the price of an individual item has been encapsulated within the CalculateItemPrice method. This adjustment enhances the readability of the CalculateTotalPrice method and ensures a clear separation of concerns. Additionally, it opens up the possibility for potential reuse of the CalculateItemPrice logic elsewhere in the codebase

The Power of Dependency Inversion Principle (DIP) in Software Development

Theodore Karropoulos — Sun, 16 Jul 2023 09:07:15 +0000

In the world of software development, there's a valuable principle known as the Dependency Inversion Principle (DIP). This principle is a game-changer when it comes to building code that is flexible, maintainable, and loosely coupled. By applying DIP, we can flip the way modules depend on each other, unlocking a range of benefits that improve our codebase and development process.

What Dependency Inversion Principle (DIP) is?

The Dependency Inversion Principle (DIP) is a concept in software development that guides how you should structure your code to make it more flexible and maintainable. In simple terms, DIP suggests that:

High-level modules or classes should not depend on low-level modules. Instead, both should depend on abstractions.
Abstractions should not depend on details. Instead, details should depend on abstractions.

In simpler terms, DIP suggests that the way modules or classes depend on each other should be inverted. Instead of high-level modules depending on low-level modules directly, they should both depend on abstract interfaces or classes.

Why DIP Matters?

DIP is crucial when we want to create adaptable, maintainable, and testable code. It shines brightest in complex systems, where components often change. Additionally, it promotes code reusability and supports collaboration among multiple developers. By embracing DIP, we can create a solid foundation for our software projects.

What are the benefits of using DIP?

By adhering to DIP, we achieve several benefits:

Loose coupling: DIP encourages modules to depend on abstractions rather than concrete implementations. This reduces tight connections between modules, making our code more modular and easier to understand and modify. We gain the freedom to update or swap components without affecting the entire system.
Flexibility: With DIP, we unlock the power to adapt and extend our codebase effortlessly. By relying on abstractions, rather than specific implementations, we can easily introduce new features, accommodate changing requirements, and seamlessly integrate alternative solutions.
Testability: DIP makes testing a breeze. By depending on abstractions, we can create mock objects or test doubles, enabling effective unit testing. We can isolate and test individual components, ensuring the reliability and quality of our software.
Scalability and Maintenance Made Easy: DIP paves the way for scalable software. It allows us to add, replace, or update components without disrupting the existing system. This scalability makes maintenance a breeze, reducing the chances of introducing bugs or complications during updates.

Code Example

As developers, let's delve into a code example to better comprehend the advantages of adhering to the Dependency Inversion Principle (DIP). In this scenario, we'll create a payment service that processes payments using credit cards. We'll begin with a suboptimal implementation that neglects DIP principles and subsequently refactor it to embrace DIP.

Poor Implementation (without DIP):

// High-level module
public class PaymentService
{
    private CreditCardProcessor _creditCardProcessor;

    public PaymentService()
    {
        _creditCardProcessor = new CreditCardProcessor();
    }

    public void ProcessPayment(decimal amount, string creditCardNumber)
    {
        // Perform payment processing using the CreditCardProcessor
        _creditCardProcessor.ProcessPayment(amount, creditCardNumber);
    }
}

// Low-level module
public class CreditCardProcessor
{
    public void ProcessPayment(decimal amount, string creditCardNumber)
    {
        // Implementation details of payment processing using a credit card processor
        Console.WriteLine($"Processing payment of {amount} using credit card {creditCardNumber}");
    }
}

// Usage
PaymentService paymentService = new PaymentService();
paymentService.ProcessPayment(100.0m, "1234 5678 9012 3456");

In our poor implementation the high-level module PaymentService directly depends on the low-level module CreditCardProcessor . The PaymentService creates an instance of CreditCardProcessor within its constructor and directly calls its ProcessPayment method. This tightly couples the high-level module to the specific implementation of the credit card processor.

Refactoring with DIP:

To align with DIP, we introduce abstractions and decouple the high-level and low-level modules.

// High-level module
public class PaymentService
{
    private IPaymentProcessor _paymentProcessor;

    public PaymentService(IPaymentProcessor paymentProcessor)
    {
        _paymentProcessor = paymentProcessor;
    }

    public void ProcessPayment(decimal amount, string creditCardNumber)
    {
        // Perform payment processing using the injected payment processor
        _paymentProcessor.ProcessPayment(amount, creditCardNumber);
    }
}

// Abstraction or interface for payment processing
public interface IPaymentProcessor
{
    void ProcessPayment(decimal amount, string creditCardNumber);
}

// Low-level module implementing the IPaymentProcessor interface
public class CreditCardProcessor : IPaymentProcessor
{
    public void ProcessPayment(decimal amount, string creditCardNumber)
    {
        // Implementation details of payment processing using a credit card processor
        Console.WriteLine($"Processing payment of {amount} using credit card {creditCardNumber}");
    }
}

// Usage
IPaymentProcessor paymentProcessor = new CreditCardProcessor();
PaymentService paymentService = new PaymentService(paymentProcessor);
paymentService.ProcessPayment(100.0m, "1234 5678 9012 3456");

In the refactored example, we embrace the Dependency Inversion Principle (DIP) to achieve flexibility and maintainability in payment processing. We introduce an abstraction called IPaymentProcessor, which acts as the contract defining payment processing behavior. By modifying the high-level module PaymentService to depend on this abstraction rather than the concrete implementation of CreditCardProcessor, we unlock a range of benefits.

The PaymentService class receives an instance of IPaymentProcessor through its constructor, following the principle of dependency inversion. This allows different implementations of IPaymentProcessor to be injected, promoting flexibility and loose coupling.

By adopting the Dependency Inversion Principle (DIP), our code gains valuable characteristics of modularity, flexibility, and testability. With DIP, we achieve decoupling between high-level and low-level modules, empowering the code to rely on abstractions. This approach simplifies the modification and extension of payment processing logic without affecting the core PaymentService class.

If you're familiar with Java or C# development, you'll find the Dependency Inversion Principle (DIP) to be a concept that resonates well. In both Java and C#, DIP is implemented using the Dependency Injection (DI) pattern and Inversion of Control (IoC) container. These powerful tools help us embrace DIP and create flexible, maintainable, and loosely coupled code.

Conclusion

The Dependency Inversion Principle (DIP) is a powerful principle that transforms our codebase. By inverting dependencies between modules, we unlock a world of benefits. DIP is the key to building code that is adaptable, maintainable, and testable. It shines in complex systems, promotes code reusability, and fosters collaboration among developers. Embracing DIP empowers us to create robust and efficient software systems that can evolve, adapt, and withstand the test of time.

Unleashing the Power of Interface Segregation: Building Flexible and Maintainable Software Systems

Theodore Karropoulos — Sun, 09 Jul 2023 12:10:17 +0000

What Interface Segregation Principle (ISP) is?

The Interface Segregation Principle is one of the SOLID principles in software engineering. The ISP states that clients should not be forced to depend on interfaces they do not use. To better understand the above statement let's take a look at the following example.

Imagine you have a big box with many different toys inside. Each toy has a specific purpose and functionality. Now let's say you are a child who wants to play with a particular toy from that box.

The Interface Segregation Principle (ISP) is like saying that you, as the child, shouldn't be forced to take the entire big box of toys when you only want to play with one specific toy. Instead, you should be given the option to pick and choose the toys you want to play with.

In the context of software development, think of the big box of toys as a software interface that provides multiple methods or functionalities. The toys inside represent the individual methods or functionalities provided by that interface.

The ISP tells us that if a client (a piece of code or a class) only needs to use a specific set of methods from an interface, it shouldn't be forced to depend on the entire interface. It should be able to choose and depend only on the methods it needs.

Code Example

Now, let's take the previous example a step further to illustrate the differences and demonstrate how applying the Interface Segregation Principle (ISP) can help us. I will provide code examples, starting with a poorly implemented version without using ISP and then followed by an improved version utilizing ISP. This will highlight the benefits of using ISP in our code design.

Poorly Implemented Version (without ISP):

// ToyBox with a big interface containing all toy functionalities
public interface IToyBox
{
    void PlayWithCarToy();
    void PlayWithDollToy();
    void PlayWithTrainToy();
    // ... and more toy functionalities
}

public class ToyBox : IToyBox
{
    public void PlayWithCarToy()
    {
        Console.WriteLine("Playing with a car toy...");
    }

    public void PlayWithDollToy()
    {
        Console.WriteLine("Playing with a doll toy...");
    }

    public void PlayWithTrainToy()
    {
        Console.WriteLine("Playing with a train toy...");
    }

    // ... implementations for other toy functionalities
}

public class Child
{
    private readonly IToyBox toyBox;

    public Child(IToyBox toyBox)
    {
        this.toyBox = toyBox;
    }

    public void Play()
    {
        // The child class is forced to depend on the 
        // entire ToyBox interface,
        // even though they only want to play with a specific toy.
        toyBox.PlayWithCarToy();
    }
}

In the above poorly implemented version, the ToyBox class has a big interface containing all toy functionalities. The Child class depends on this entire interface. even though we only want to play with a car toy. This violates the ISP since the client is forced to depend on interfaces they do not use.

Restructured Version (using ISP):

// Smaller, more focused interfaces for individual toy functionalities
public interface ICarToy
{
    void PlayWithCarToy();
}

public interface IDollToy
{
    void PlayWithDollToy();
}

public interface ITrainToy
{
    void PlayWithTrainToy();
}

public class CarToy : ICarToy
{
    public void PlayWithCarToy()
    {
        Console.WriteLine("Playing with a car toy...");
    }
}

public class DollToy : IDollToy
{
    public void PlayWithDollToy()
    {
        Console.WriteLine("Playing with a doll toy...");
    }
}

public class TrainToy : ITrainToy
{
    public void PlayWithTrainToy()
    {
        Console.WriteLine("Playing with a train toy...");
    }
}

public class Child
{
    private readonly ICarToy carToy;

    public Child(ICarToy carToy)
    {
        this.carToy = carToy;
    }

    public void Play()
    {
        // The child class can now depend 
        // only on the specific toy interface 
        // they want to play with,
        // adhering to the Interface Segregation Principle (ISP).
        carToy.PlayWithCarToy();
    }
}

In this restructured version, we create smaller more focused interfaces representing individual toy functionalities. The Child class can now depend only on the specific toy interface they want to play with, aligning with the ISP. This allows for better code organization, reduced dependencies and improved flexibility in extending or modifying the codebase.

Conclusion

In conclusion, adhering to the Interface Segregation Principle (ISP) brings forth a multitude of benefits. By following ISP, we can achieve a codebase that exhibits reduced coupling, improved modularity, enhanced maintainability, better testability, and flexible extensibility.

By reducing coupling, ISP minimizes dependencies between modules or classes, leading to code that is more independent and modular.

Additionally, ISP improves maintainability by limiting the impact of changes. Clients only rely on the specific methods they use, so modifications to other parts of the codebase do not affect them. This reduces the risk of unintended side effects and makes the system easier to maintain and evolve.

Furthermore, ISP enhances testability by enabling focused unit testing. Smaller more specific interfaces allow for targeted tests.

Lastly, ISP enables flexible extensibility by introducing new interfaces and implementing them as needed, we can easily add new functionality without modifying existing code.

To sum up, by embracing the Interface Segregation Principle (ISP), we foster a software design characterized by loose coupling, modularity, maintainability, testability and adaptability.

DEV Community: Theodore Karropoulos

[Boost]

Refactoring: The Art of Crafting Cleaner, Smarter, and More Maintainable Code

Theodore Karropoulos ・ Dec 10

Refactoring: The Art of Crafting Cleaner, Smarter, and More Maintainable Code

Introduction

What is Refactoring?

Why Refactoring Matters

Common Refactoring Techniques

Extract Method

Move Method

Replace Magic Numbers with Constants

Introduce Parameter Object

Tips for Effective Refactoring

Conclusion

Integration Testing in .NET: A Practical Guide to Tools and Techniques

What Exactly is Integration Testing?

When to Use Integration Testing?

Tools for Integration Testing in .NET

1. xUnit & NUnit

2. Entity Framework Core In-Memory Database

3. Testcontainers for .NET

4. WireMock.Net

5. Moq for Dependency Mocks

Best Practices for Integration Testing

Conclusion

Streamlining Your Tests with IClassFixture in xUnit

Introduction

What is IClassFixture?

Why is IClassFixture Important?

Getting Started with IClassFixture in .NET

Practical Example: Testing a Dinner Party Service

When to Use IClassFixture

Techniques for Effective use of IClassFixture

Conclusion

Unit Testing in .NET: Tools and Techniques

Introduction

What is Unit testing?

Why is Unit Testing Important?

Getting Started with Unit Testing in .NET

Testing Multiple Inputs

Techniques for Effective Unit Testing

Conclusion

The Differences Between EntityFramework .Add and .AddAsync

Introduction

What is DbSet<TEntity>.Add?

What is DbSet<TEntity>.AddAsync?

Key Differences Between Add and AddAsync

Exploring C# Custom Types: Understanding Records, Structs, and Classes

Introduction

What is a class?

Example

What is a Struct?

Example

What is a Record?

Example

When to Use Each

Comparing Class, Struct, and Record

Understanding IQueryable in C#

Introduction

What is IQueryable

When to use IQuearyable

Differences between IQueryable and IEnumerable

Deferred Execution

Query Composition

Supported Query Operators

Mastering Resource Management in C# with the Disposable Pattern

Understanding the Disposable Pattern:

How Does It Work?

Conclusion:

Extract Method Refactoring

Extract Method

Simple Explanation:

Example of Extract Method (Before):

Refactored Code using "Extract Method" (After):

The Power of Dependency Inversion Principle (DIP) in Software Development

What Dependency Inversion Principle (DIP) is?

Why DIP Matters?

What are the benefits of using DIP?

Code Example

Techniques for Effective use of `IClassFixture`

What is `DbSet<TEntity>.Add`?

What is `DbSet<TEntity>.AddAsync`?

Key Differences Between `Add` and `AddAsync`