Forem: 🧑‍💻 Kamil Bączek

Evolutionary Architecture by Example 🚀

🧑‍💻 Kamil Bączek — Mon, 18 Sep 2023 11:58:23 +0000

Hey there, fellow developers and architects!

We're thrilled to introduce our latest project, the "Evolutionary Architecture by example" repository. This collaborative effort, brought to you by Maciej Jedrzejewski and me, represents countless hours of dedication and hard work. Join us on a journey into the intricate world of architectural evolution within the .NET ecosystem.

evolutionary-architecture / evolutionary-architecture-by-example

Navigate the complex landscape of .NET software architecture with our step-by-step, story-like guide. Unpack the interplay between modular monoliths, microservices, domain-driven design, and various architectural patterns. Go beyond the one-size-fits-all solutions and understand how to blend these approaches based on your unique needs.

Evolutionary Architecture

Table of Contents

Objective

Problem

There are many repositories that describe software and solution architecture in .NET. As there is no single definition of software architecture, they combine several topics:

Deployment strategies like Modular Monolith and Microservices
Domain-Driven Design
Clean, Onion, Hexagonal Architecture
Infrastructure

as if each of the above were the only possible solution. And that is the problem - it is very rare that any single material shows you a concrete decision path or mix…

View on GitHub

What's Inside 🏗️

In-depth explorations of various architectural styles
Real-world examples that vividly depict the context and interactive approach to architectural thinking
One of architecture evolutionary steps diagrams
Code samples and comprehensive documentation to help you hit the ground running

Our primary goal with this project is not just to showcase architectural styles but to provide you with a comprehensive resource for understanding how architecture can adapt and thrive in the ever-changing landscape of software development.

Why 'Evolutionary Architecture'? 💡

We firmly believe that architecture should not be a one-size-fits-all concept. Instead, it should evolve and adapt as projects and requirements evolve. Our repository aims to empower developers like you with the knowledge and examples needed to make informed architectural decisions.

We Want Your Feedback 🤔

We're eager to hear your thoughts, feedback, and contributions. Dive into the repo and let us know what you think! Your input will play a crucial role in shaping the future of this project.

Feel free to explore, fork, and contribute to the codebase. Your expertise can help make this resource even more valuable to the community.

Thank you for joining us on this exciting journey into the world of evolutionary architecture. We can't wait to see how it benefits your projects and your understanding of architecture in the .NET ecosystem.

Stay curious, stay innovative, and happy coding! 🚀

🔥Utilizing Feature Flags in Monoliths: A Simple yet Powerful Enhancement for Agility 🚀

🧑‍💻 Kamil Bączek — Sun, 13 Aug 2023 08:10:29 +0000

📚 Tl;dr

Feature flags: Dynamic switches altering application behavior without code changes.
Advantages in modular monoliths:
- Dynamic Module Management: Enable/disable modules based on flags during startup.
- Testing and Isolation: Independent testing of modules, simplified troubleshooting.
- Scaling with Agility: Scale necessary parts based on workload, maintaining cohesion.
Transitioning to Microservices: Consider when flag-based scalability gets complex; assess pros and cons.
Integrating in .NET:
- Install/register Microsoft NuGet package for easy feature flag handling.
Conclusion:
- Impact: Reshapes modular monoliths for agile development, testing, and scalability.
- Benefits: Enhanced module management, isolated testing, strategic scaling.

🏆 How Feature Flags enable monolith agility❓❓

Feature flags, those dynamic conditional switches that can be swiftly altered, have emerged as a game-changer for modern software development. They empower developers to control the behavior of their applications without changing code, facilitating better testing, scalability, and a more agile development process. In this post, let's delve deeper into how feature flags can be a game-changer for modular monolith architectures, and how they can enable efficient module management and enhanced scalability.

🔗 Dynamic Module Management with Feature Flags

In the world of modular monoliths, managing and evolving individual modules can be quite challenging.

This is where feature flags come to the rescue. By utilizing feature flags during application startup, you can dynamically enable or disable modules based on their respective feature flag states. This means that during initialization, you can make decisions on whether to register a particular module's dependencies or skip them entirely.

🧪 Empowering Testing and Isolation

Feature flags play a pivotal role in enhancing your testing strategies. By enabling the isolation of modules, you can test them independently. This not only streamlines the testing process but also reduces the complexities of troubleshooting issues. Your development teams can focus on perfecting one module at a time without having to grapple with intricate dependencies or entangled code, they don’t have to setup configuration from others module and test only public interfaces or message consumers.

🌐 Scaling Strategically with Agility

Scaling modular monoliths can be a double-edged sword. Transitioning to microservices for the sake of scalability can introduce a slew of operational and architectural complexities.
Feature flags provide an alternative avenue.

By enabling the dynamic activation of modules, you can selectively scale only the required parts of your application. This approach proves especially powerful when dealing with variable workloads, where some modules might require more resources than others.

As your project's demands increase, feature flags let you scale the necessary modules while maintaining the overall cohesiveness of your monolith.

💡 When to consider extraction

While feature flags grant incredible flexibility, there might come a point when scaling via flags becomes cumbersome or leads to a convoluted codebase. If feature flag-based scalability starts to hinder development agility, it might be time to consider transitioning specific modules into microservices. However, this decision should be made judiciously, considering the added complexity and operational overhead associated with microservices architectures.

🔗 This is really simple!

Integrating feature flags into a .NET environment is remarkably uncomplicated. Through the installation and registration of the Microsoft NuGet package, you can effortlessly handle feature flag configuration.

🚀 In Conclusion

Feature flags are a dynamic force that can reshape the landscape of modular monoliths. By enabling dynamic control over module activation and deactivation, feature flags pave the way for more agile development, enhanced testing strategies, and strategic scalability. So, whether you're looking to optimize your monolith or cautiously venture into microservices territory, feature flags can be your guiding light toward a more efficient and adaptable software architecture.

Follow me

🚀 If you're looking for ways to improve your software development skills and stay up to date with the latest trends and best practices, be sure to follow me on dev.to!📚 I regularly share valuable insights and tips on software development, as well as updates on my latest projects.

Speaking of projects, I'd like to invite you to check out my modular monolith project on GitHub💻, called Estimation Tool. It's a great example of how you can use modularization to build a more scalable and maintainable system. The project is open-source and well-documented, so you can learn by example and see how I applied the concepts of modularization in practice.

https://github.com/kamilbaczek/Estimation-Tool 🔗

So if you're looking to level up your development skills, be sure to follow me on dev.to and check out my modular monolith project on GitHub. Happy coding!🎉

🚀 Mastering Modularization: Embracing Simplicity: Simplifying your codebase with Deletion Thinking 🧠

🧑‍💻 Kamil Bączek — Mon, 19 Jun 2023 05:42:26 +0000

Improving software design can greatly increase team productivity by allowing developers to refactor easily, propose improvements, and take initiative.

Well-defined interfaces between software modules, such as public classes, methods, endpoints, or events, are crucial for effective communication.

One way to judge if a software module is well-defined is to use deletion thinking , which involves evaluating the number of changes required to remove the module and questioning whether all public interfaces are necessary.

During the design phase, ask yourself: *how many changes will be needed to remove this software piece? * Then, analyze each change to see if any publicly exposed implementation details can be rearranged to hide the mechanism’s implementation

Good architecture is not just about building a structure that stands upright. It’s about creating a design that allows you to easily change or remove parts of it as needed.

To streamline the process of disabling a module, I like to use feature flags during the module dependencies registration (implementation details registrations).

By doing so, I can quickly disable a business process or capability. Determine the number of feature flags required to disable a module, much like using deletion thinking.

It’s essential to double-check software design and implementation to ensure it’s robust and efficient. By considering these critical questions during software development, you can create better-designed software.

The post Mastering Modularization: Deletion Thinking appeared first on ArtOfSoftwareDesign.

📈 Boost Your Integration Testing for REST APIs with Snapshot Testing in .NET

🧑‍💻 Kamil Bączek — Tue, 11 Apr 2023 14:28:00 +0000

⚡ TD:LR

Tests are crucial for software projects, but they should be easy to maintain.
Classic assertions can become difficult to maintain when contracts change.
Snapshot testing is an alternative approach to classic assertions.
In snapshot testing, the first test result is recorded as a snapshot, and subsequent tests are compared against it.
Snapshot testing makes it easier to maintain tests as the contract changes.
The article provides a step-by-step guide to implementing snapshot testing for integration tests.
Snapshot testing has pros and cons, and it’s important to be aware of its limitations.

Testing is a crucial aspect of any software project 🧪

Tests are necessary to improve and evolve the project. However, with great power comes great responsibility, and tests should be easy to maintain; otherwise, our development process will slow down.

In this article, we will focus on integration testing, particularly for a REST API endpoint that returns a paginated list.

Classic Assertions Problem 🤯

There are several ways to assert the results of an API test, such as hard-coding expected items and asserting one item or hard-coding all items and asserting all items. However, when the API is nested and the contract changes, you will need to rewrite your assertions, and you may need to modify several places.

How to make assertions easier to maintain❓

i would like to highlitht snapshot testing approach (another words approval testing).

Approval testing is a different approach to asserting results. In snapshot testing, we execute the test for the first time and record the output as a snapshot. We then compare subsequent test results against this snapshot to ensure that the API is still behaving as expected. This approach makes it easier to maintain tests as the contract changes since we only need to update the snapshot instead of multiple assertions.

Let’s skip the theory and proceed step by step.

Step by step Guide 📘

As you can see, these integration tests are quite ordinary except for one particular feature: the classes have an attribute called [UseVerify]. Instead of using traditional assertions, the test results are passed to a function called Verify().

To work effectively with snapshot testing, I use the Rider Plugin. (Verify Support)

Like you can see on digram we are on the state when we never executed a test a we don’t have snapshot. During Verify function execution git diff window opens.

I am reviewing the results of the tests conducted on my function. Based on the test results, I have the option to approve them as expected or reject them and attempt to fix the test. After making any necessary corrections, I can review and approve the results again.

After approval, a text file containing the results is created. This is known as a snapshot.

For example, if we broke something and the method doesn’t return a filled list but instead an empty one, the test will fail.

When adding a property to the contract, a diff will be opened.

After reviewing the changes, you can approve them if they appear correct.

Although we have made changes to the functionality, the modification of the tests is minimal.

Use Cases 🤔

It may be worth considering the use of approval testing in cases where writing traditional assertions with loops to cover a large amount of data is time-consuming or difficult. This is particularly true when dealing with complex assertions. For example:

testing the output of a report endpoint,
parsing results from files
verifying the results of complex data aggregation endpoints
apr results that is large or complex data structures, where traditional assertion-based testing may not be practical.
snapshot testing can be used to verify that database queries it is useful when dealing with complex queries that involve multiple joins and filters.

Learn by example 📖

Product Inventory Example

Trade off analysis 🔖

👍 Pros:

Snapshot testing makes it easier to maintain tests as the contract changes.
It reduces the number of assertions required for testing.
It reduces the complexity of tests and improves readability.
It allows developers to see the difference between the current test output and the previous one.
It is more flexible than traditional assertion testing, allowing developers to test a wide range of scenarios with a single snapshot.

👎 Cons:

The test results may be invalid if the developer approves them without reviewing them carefully.
Snapshot testing may not be suitable for testing scenarios that involve randomness or unpredictable outputs.
It may not be as precise as traditional assertion testing because it only checks if the output has changed, not how it has changed.
It may require additional tooling or plugins to work effectively, which may add complexity to the testing process.

As with most things, there are trade-offs. While I like this technique and agree with its consequences, it is important to be aware of its limitations.

Follow me

https://github.com/kamilbaczek/Estimation-Tool 🔗

So if you're looking to level up your development skills, be sure to follow me on dev.to and check out my modular monolith project on GitHub. Happy coding!🎉

Types complexity in software systems

🧑‍💻 Kamil Bączek — Fri, 27 Jan 2023 19:26:14 +0000

There are different types of complexity in the IT system. Understanding the types of complexities we face will help us make better design and architectural decisions. Adapt techniques to the problems we want to solve.

Domain complexity

Domain complexity, as the name suggests, is the complexity of the business problem that a given system is to solve. For example, we create a system in which you can insure real estate. Realty arrangements have many conditions that only insurers know. A programmer who was not previously involved in the insurance industry will be initially overwhelmed with the number of dependency rules and terminology applicable in this industry.

Failure to deal with this type of complexity causes:

High Coupling
Overengeering
Team member rotation

Failure to understand the domain often results in the fact that even a greenfield project quickly becomes hard to maintain.

How to fight with domain complexity?

A set of proven techniques in battle is Domain Driven Design described by Eric Evans. Strategic patterns are especially noteworthy because they provide tools on how to communicate with people from business. It allows us to gain knowledge about business processes. Extract the core of the system. Finding a shallow and deep places in system.

Accidencal complexity

Random sensitivity is present in every IT system. It is especially visible in the legacy in systems. Each of us probably had a simple task to do. For example, add one field to the UI. We evaluate such tasks for one manday. We go to the place in the code where we have to add this field. It turns out that the code is incomprehensible and operates on reflection and dynamic types. Somehow we managed to do it in one manday. The next day, the tester tells us that we’ve broken something elsewhere. Combination and repair takes another mandays two days. We are finally done with the tasks.

Accidental complexity contributed to not deliver task on time.

How to fight Accidencal complexity?

We should fight against accidental complexity first of all with Refactoring. In line with the “Scout Boy” rule. If we go into some code we become the better one. In the future there will be an entry on “Countinous Refactoring” where this topic will be more relevant. Another tool to combat this type of complexity is abstraction. Sometimes a good technique is to cut yourself off the legacy code with create new module. In this new module we will create new code in good way. For the old legacy code we will create abstraction and use this abstraction in our new module.

Summary

Each IT project is different, in some we have a complex domain, and in another problem is randomness. Sometimes we have both. We already know that we can fight a complex domain with Domain Driven Design. In case of accidental complexity we use modularity and refactoring. It is worth educating your knowledge in those topics. Introducing the discussed elements to your project so that the business earns more and the developers have a more pleasant work.

👮 Architecture Governance: Keeping Your System's Design on Track with Continuous Arch Testing

🧑‍💻 Kamil Bączek — Sun, 22 Jan 2023 23:00:00 +0000

📚 Tl;dr

Architecture governance is a system for maintaining consistency and quality in architectural decisions throughout the development process of a software project.
It involves having control over architectural rules and guidelines and ensuring they are adhered to.
Fitness function is an important component of architecture governance which acts as a "cop" to ensure developers don't break established architectural rules and measures the alignment of the software architecture with business goals.
NetArchTest is a tool that can be used to implement the automatic fitness function by writing unit tests that check dependencies between packages, classes, and methods in the codebase.

📐 What is architecture governance?

When building software projects, there are many architectural decisions that need to be made. It is important to maintain consistency in these decisions to ensure the overall quality and maintainability of the project.

Having a system for architecture governance allows the team to have control over the architectural rules and guidelines, and to ensure that they are being adhered to throughout the development process. This can help to ensure that the project remains on track, and that any issues or inconsistencies are identified and addressed in a timely manner.

Additionally, having a well-defined architecture governance system can facilitate collaboration and communication among team members and help to ensure that everyone is working towards the same goals. This can lead to a more cohesive team and a better end product.

It's also important to note that architecture governance is not a one time process, but a continuous one that adapts to the changes of the project and the organization. That way, the team can ensure that the software architecture is aligned with the business goals and the evolving requirements.

👮 Fitness function

Fitness function is a way to measure the alignment between the software architecture and the business goals.

One approach to implementing a fitness function is through the use of automatic fitness functions. Automatic fitness function will be in our case units that will check the validity of architecture decisions.

🚀 NetArchTest comes to play

NetArchTest is a library that can be used to write such tests (automatic fitness functions), it allows to check the architecture and ensure that it adheres to predefined rules and constraints.

With NetArchTest, developers can write unit tests that check the dependencies between different packages, classes, and methods in their codebase. This can be useful for checking that the architecture adheres to principles such as separation of concerns and the single responsibility principle. By running these tests regularly, developers can ensure that the architecture remains consistent and that any changes to the codebase do not violate the predefined rules. ADR and Arch unit test is amazing mix that will help you keep consistant great design.

📐 Example 1️⃣

ADR 1: Creating a Custom Shared Logging NuGet Package for Improved Performance and Maintainability.

Status

Approved

Context

We have identified that the current using the Microsoft ILogger interface does not provide optimal memory efficiency and there is inconsistent code optimization across our solution. This can lead to performance issues within our codebase. Additionally, having a consistent logging implementation across the solution will make it more maintainable and easier to understand.

Decision

We have decided to develop a custom shared logging NuGet package with “IOptimizedLogging” interface to improve the efficiency of our logging system.

Consequences

👍 Pros:

Improved memory efficiency: The custom shared logging NuGet package will improve the memory efficiency of the logging system, as the optimized implementation will be used consistently throughout the solution.
Improved performance: The package will also improve the performance of the logging system, as the code that optimizes log execution will be consistently implemented throughout the solution.

👎 Cons:

Increased development and maintenance effort: The development of a custom shared logging NuGet package will require additional resources and effort, including the development and testing of the package, as well as its ongoing maintenance and updates.
Each new developer or current one has to know that he must use IOptimizedLogger instead ILogger

👮 Fitness Function

📐 Example 2️⃣

ADR 2: Notifications module should be decupled by events

Status

Approved

Context

The team has determined that the current design of the notifications modules, which relies on coupling via interfaces, is not flexible enough to allow for easy integration with other modules.

Decision

The decision is to decouple the notifications modules by using events as the only method of integration, where other modules can publish integration events can be consumed by the notifications modules event handlers.

Consequences

👍 Pros:

Increased flexibility in the overall system design
Easier integration with other modules
Improved maintainability of the codebase
Reduced dependencies between modules
Cons of decoupling notifications modules by using events:

👎 Cons:

Additional complexity in the codebase
Additional overhead of managing events and event listeners
The need to re-architect the current notifications modules
More difficult to debug and troubleshoot if there are issues with the event-based communication.

👮 Fitness Function

📚 Description

Checks that any interfaces or class from notifications modules is used in other modules. This checks compliance with a predetermined ADR to avoid coupling via interfaces in the notification module. It is used as a means of ensuring that the code base complies with this ADR and that new developers do not introduce violations of this decision by their lack of knowledge.

👮 Fitness Function

📚 Description

This function verifies that the notification module has event handlers that only consume integration events. It is used to ensure that the notification module adheres to an architectural decision (ADR) that specified that the module should be integrated with other modules through events. The function is checking that this design decision is being followed.

🏁 Summary

Architecture governance is a system for maintaining consistency and quality in architectural decisions throughout the development process of a software project.

It involves having control over architectural rules and guidelines, and ensuring they are adhered to. It also promotes collaboration and communication among team members, and helps to align the software architecture with business goals and evolving requirements.

A key component of architecture governance is the use of a fitness function, which acts as a "cop" to ensure that developers do not break established architectural rules and measures the alignment of the software architecture with business goals. One way to implement this is through automatic fitness functions, such as using NetArchTest, a library for writing unit tests that check dependencies between packages, classes, and methods in the codebase to ensure adherence to predefined rules and principles such as separation of concerns and the single responsibility principle.

🔗 References

Software Architecture: The Hard Parts Book

Kamil Grzybek Modular Monolith has arch tests examples

Architecture Fitness Functions Talk

NetArchTest Project

🤝🏻 Follow me

https://github.com/kamilbaczek/Estimation-Tool 🔗

So if you're looking to level up your development skills, be sure to follow me on dev.to and check out my modular monolith project on GitHub. Happy coding!🎉

🔧 Mastering Modularization: A Beginner's Guide to Organizing Complex Software Systems

🧑‍💻 Kamil Bączek — Fri, 13 Jan 2023 18:17:56 +0000

⚡ Tl;dr

Modularization is a method of dividing complex systems into smaller, manageable parts for better management and understanding.
It improves the efficiency, reliability, and maintainability of software projects by organizing code into modules.
It reduces cognitive load for developers by decreasing the amount of information they need to process at one time, making complex systems easier to understand and preventing burnout.
Modules in software development can be thought of as building blocks, like lego pieces.
Each module has a unique set of public interfaces, data structures or messages that act as contracts for other developers to use.
When working with modules, it's important to treat them as black boxes and only interact with them through their defined public interfaces to avoid coupling and improve the modularity of the system.
In .NET, a module is a self-contained piece of code that serves a specific purpose or function and can be imported and used in other pieces of code.
Assemblies are used to group code in .NET because they allow for a higher level of encapsulation (using internal access), which allows developers to control the level of access other code has to the members of a type and helps to protect the implementation details of a type or member.
To make implementation visible for test, you can use attribute in the csproj file and specify the test project assembly name.

🧩 Why Developers Neglect Modularization?

One reason developers may not prioritize modularization is a lack of knowledge on the subject. Developers often learn languages and frameworks from documentation, which may not emphasize best practices for organizing code and creating modules.

🤷‍♂️ Another factor may be a lack of understanding about business processes and system domain, which can lead to unrelated pieces of code being closely tied together.

🤔 Additionally, developers may focus too much on technologies and frameworks that help them build a project quickly, rather than considering business processes and connections between them.

😟 Poor design and a lack of modularization can lead to the need for a project to be completely rewritten, while using certain frameworks or technologies may not necessarily have the same impact.

🧠 Why is modularization considered so valuable in software development?

Modularization 🧩 is a method of dividing complex systems into smaller, manageable parts for better management and understanding. It is based on the principle of "divide and conquer" and improves the efficiency, reliability, and maintainability 🔧 of software projects by organizing code into modules.

It also reduces cognitive load 🧠 for developers by decreasing the amount of information they need to process at one time, making complex systems easier to understand and preventing burnout 💀.

🧱The Lego Principle: Use Modules as the Building Blocks of Your Software Systems

Modules in software development can be thought of as building blocks, like lego pieces. Each module has a unique set of public interfaces, data structures or messages that act as contracts for other developers to use. When working with modules, it's important to treat them as black boxes and only interact with them through their defined public interfaces. This helps to avoid coupling and improve the modularity of the system.

One common mistake I've seen in projects is when all classes are made public, which means modularization doesn't exist. Everything is touchable and can be coupled with any other element, leading to a fast path to a "big ball of mud" 💩💩 that we want to avoid 🙅‍♂️.

High coupling module example. Avoid it !!!

To prevent this, it's key to use the internal access modifier 🔒 and only expose a clean, well-defined API using public interfaces and data structures that are easy to consume. Test-driven development (TDD) 🧪 can also help with this, as the first consumer of your module will be yourself. By following these practices, you can create a modular system that is easy to understand, maintain, and extend.

🧱 Module Example in .NET

A module is a self-contained piece of code that serves a specific purpose or function, and can be imported and used in other pieces of code. It helps to organize and make code more reusable, and is often used in software development to break up large projects into smaller, more manageable pieces.

🤖 Module in .NET

Module is single Assembly or set of assemblies grouped by Solution Folder

Divstack Estimation Tool - Emails module view

Divstack.Company.Estimation.Tool.Emails.Core is example of sub module of Emails Module. This module gives technical capability to sending Emails. Purpose is to be reusable.

Why assemblies are used to group code? Why not dictionary?

The Divstack.Company.Estimation.Tool.Emails.Core assembly is an example of a submodule of the Emails module that provides the technical capability for sending emails. It is designed to be reusable.

One reason for using assemblies to group code is that they allow for a higher level of encapsulation. Access modifiers such as internal and public allow developers to control the level of access other code has to the members of a type, which helps to protect the implementation details of a type or member.

In contrast, using a dictionary approach would not allow for the same level of encapsulation, as it would not support access modifiers and would always provide access to the class.

💪🏼 Let’s go to example

In this module there is only two public classes.



public interface IEmailSender
{
    void Send(string email, string subject, string text);
}



public static class EmailCoreModule
{
    public static IServiceCollection AddCore(this IServiceCollection services)
    {
        services.AddScoped<IEmailSender, EmailSender>();
        services.AddSingleton<IMailConfiguration, MailConfiguration>();
        services.AddScoped<IMailTemplateReader, MailTemplateReader>();

        return services;
    }
}

Other classes are implementation details

A module is like a black box for other developers. They only have access to the interface provided by the module, and don't need to worry about how it is implemented. This can be either a service like SendGrid or a standard SMTP server. The advantage of this approach is that it doesn't matter how the module is implemented, as long as it provides the expected functionality through the interface.

📦 The Power of the Black Box Approach

A public API should be stable, meaning that it should not change frequently or unexpectedly. It is important for the developer to carefully design the interface of the API to make it easy to understand and use 🧑‍💼. This is similar to the importance of designing a pure REST API. One way to ensure that the API is developer-friendly is to use unit testing 🧪, as tests can serve as the first "client" of the code 💻. That is why it is often recommended to use a technique called Test-Driven Development (TDD) 🧑‍💻, in which tests are written before the implementation code. By writing tests first 🧑‍🔬, the developer can focus on designing a clean and easy-to-use interface for the API.

🔧 How to test encapsulated module implementation?

A common problem with understanding unit tests is understanding the word 'Unit'. In our modules, we will have a public interfaces. In our unit tests, we will be testing the implementation of the interface whose has public access modifier.



public interface IEmailSender
{
    void Send(string email, string subject, string text);
}



internal sealed class EmailSender : IEmailSender
{
    private const string EmailType = "text/html";
    private readonly IBackgroundProcessQueue _backgroundProcessQueue;
    private readonly IMailConfiguration _mailConfiguration;

    public EmailSender(IMailConfiguration mailConfiguration, IBackgroundProcessQueue backgroundProcessQueue)
    {
        _mailConfiguration = mailConfiguration;
        _backgroundProcessQueue = backgroundProcessQueue;
    }

    public void Send(string email, string subject, string text)
    {
        if (!IsNullOrEmpty(_mailConfiguration.MailFrom))
        {
            _backgroundProcessQueue.Enqueue(() => SendMessageAsync(email, subject, text));
        }
    }

    public async Task SendMessageAsync(string email, string subject, string text)
    {
        var client = new SendGridClient(_mailConfiguration.ApiKey);

        var message = BuildMessage(email, subject, text);

        await client.SendEmailAsync(message);
    }

    private SendGridMessage BuildMessage(string email, string subject, string text)
    {
        var message = new SendGridMessage();
        message.AddTo(email);
        message.AddContent(EmailType, text);

        var fromEmailAddress = new EmailAddress(_mailConfiguration.MailFrom);
        message.SetFrom(fromEmailAddress);
        message.SetSubject(subject);

        return message;
    }
}

To make it visible for test project we have to add this code to Divstack.Company.Estimation.Tool.Emails.Core.csproj file.



<ItemGroup>

    <InternalsVisibleTo Include="Divstack.Company.Estimation.Tool.Emails.Core.UnitTests" />

  </ItemGroup>

🔖 Summary

It is important to note that modularization is a powerful technique that can help improve the overall quality of your code and make it more maintainable and testable. With the proper use of the internal access modifier and following best practices, developers can create a modular system that is easy to understand, maintain, and extend.

This was a basic introduction to modularization in .NET. In the future, more information will be provided on topics such as:

Module extraction
Module definition heuristics
Modular monolith architecture
Feature slices

This series will be continued..

🔗 References

Follow me

https://github.com/kamilbaczek/Estimation-Tool 🔗

So if you're looking to level up your development skills, be sure to follow me on dev.to and check out my modular monolith project on GitHub. Happy coding!🎉

Why Integration Tests are 'must have' to deliver high quality software?

🧑‍💻 Kamil Bączek — Tue, 20 Dec 2022 07:18:26 +0000

Testing is a very important part of the SDLC. Sometimes I've seen projects where there are only unit tests, omitting integration tests.

When I asked the development teams why they weren't there, I got different answers:

We have a good coverage of unit tests, that's enough
We had these tests but they were flaky, so we don't develop them
Its hard to write first test and we have no time now to write them

Good unit test coverage is not enough in most cases.

Why?

Unit tests provide certainty in Core places where we have business rules.

They ensure us that logic and calculation works as expected. They cannot check integration between components because they are work in isolation.

Integrations tests can ensure integration of components work properly. In addition:

serialization
dependency injection registration
database configuration
data persistance
schema migrations
http clients etc.

Without integrations tests we are not enough confident to put our code to production, without manual regression tests. That makes real CI/CD impossible.

According to test pyramid.

I would use suggest a lot of unit tests where we have logic + a few integration tests to cover e.g happy path with one variant of logic and negative path.

If there is no logic i will write only integrations tests.

There are many ready-made libraries that make our lives easier.

For example, WireMock can be used to mock responses from the external systems that we are integrating with.

When we use events for integration we can use queue simulator and simulate event publishing. Test our whole module in isolation.

To sum up, Unit test can check logic but won't tell us that application behaves correctly. Unit Test with Integration tests can do it. With such a combination plugged into CI/CD pipeline you and your team should be pretty confident when you release new version of your code. First test can be difficult to write but it's is worth it. If your team will embrace the speed of implementations and thus the quality of the code will increase significantly.

Clean Unit Testing Part II - Give a context for your 'Arrange ' test body part

🧑‍💻 Kamil Bączek — Fri, 04 Nov 2022 06:37:33 +0000

I've seen many times that unit tests were hard to read and maintain. The Tests in which the preparation of the test did not fit on the monitor. The different parts of the test were mixed and obfuscated. Unit tests have to be clear and easy to maintain to bring us value.

Good programmers write code that humans can understand - M. Fowler (1999)

I think this quote tells us that we should focus on naming things, continuously refactoring and creating a class that has a single responsibility. The same rules we should apply to unit testing.

I want to give you a few pieces of advice on how we can write cleaner tests.

Let's go to examples

Our goal is to make sure when the user password is the expired application will generate a reset password token.

Bad Tests

We have many mock setups. In this, the arrangement part of the test is huge. This is a major issue that I've seen. At first glance, it’s hard to locate the method that we are testing. We have some hard-coded test data. The data format is not close to real data. This code is not easy to read for a human to understand what we are testing and how we are testing.

Lets fix it.

Fakers

The first thing we’ll do in our refactoring is getting rid of creating objects for testing in a non-elegant way. We will get rid of magic strings. We can extract the creation of objects like SignInCommand or UserAccount to static classes with a factory method. Test data to create these objects, we can use the Faker.NET library which gives the possibility to interfere with fake mail, phone number, first name etc.

As we can see in UserAccountFaker class. We have used Faker.NET to generate a fake email and first name. Generated that is closer to real compared to some ‘testtest’ phrases.

Then we used this faker in line 41.

Mock Setups

For me, mocking framework API not looks good. It is easy to lose context here and obfuscate test code. To improve readability and give context to the code the same as is in production code in tests we can use private methods. By creating a private method you can give a meaning-full name for this mock setup e.g
"TimePassage". Please compare the Good and Bad test examples now. I'm sure that you can see the difference in readability, cognitive load is lower.

A lot of private methods on the bottom of the file do not look good to me. How do I handle this? I will explain this in the next post from this series.

COUNTER ARGUMENTS

Writing each test in that way will take too much time.
Answer:
Using IDE you can extract classes, and methods, and create factory methods in seconds. I recommend that you familiarize yourself with the keyboard shortcuts and the capabilities of IDE Rider or Visual Studio + Resharper.

I would prefer to see all code on one screen not hiding implementations of mocks or fakers.

Answer:
The human brain can take a certain dose of information at a time, if the preparation of the test is too complicated it will be difficult for you to understand at a glance. You will have to read it multiple times to understand how it works. Which will drastically affect productivity. In my opinion, it is better to divide the code into smaller fragments and when we are curious about the implementation or suspect a bug, it enters the private method to see something in it.

Summary

In summary, by extracting data preparation to Fakers and naming setup mocks. We improve readability and understanding of unit testing. This is a bit of pragmatic advice that can be implemented in any project at any time.

Take care of your cognitive load and productivity. See you on the next article 💪💪💪