Every developer, sooner or later, faces the challenge of refactoring a project that started as a proof of concept but ended up in production.<\/p>\n\n\n\n
For me, this is an exciting task. It gives me the opportunity to learn new things, complain about \u201cwho the hell wrote this code?\u201d<\/em>, and apply my knowledge to make the code cleaner and more maintainable.<\/p>\n\n\n\n At the same time, refactoring can be quite tricky\u2014especially when the project is already in production and \u201cworks fine\u201d<\/em>, but adding new features has become difficult, the service is struggling to scale, and worst of all, there are no tests.<\/p>\n\n\n\n This series is built around practical examples. You can find the full code on GitHub<\/a>.<\/p>\n\n\n\n The OrderService<\/em> from Lesson-00<\/a> has several issues. Despite being a small service, the code is already quite intricate. Technical concerns and business logic are not properly separated into clear abstractions, and cognitive complexity has not been considered at all.<\/p>\n\n\n\n But the most alarming issue? There are absolutely no tests\u2014of any kind.<\/p>\n\n\n\n How can you ensure that the OrderService<\/em> will still work the same way after refactoring? Would you take the risk of refactoring, merging the Pull Request, and deploying to production?<\/p>\n\n\n\n Tests are the key to confidence. A well-designed test suite allows you to develop new features or refactor existing code with the assurance that you can always run the tests to verify whether the code still behaves as expected.<\/p>\n\n\n\n In fact, a failing test can sometimes be reassuring\u2014it means the tests are doing their job, catching issues before they reach production, and giving you time to fix them.<\/p>\n\n\n\n Now that we understand the importance of tests, we should already know the first step before refactoring OrderService<\/em>: write tests! But what kind of tests?<\/p>\n\n\n\n Unit tests verify the behavior of individual components or units<\/em> of code in isolation. In object-oriented programming, this usually means testing a single class or method. They\u2019re invaluable during development\u2014they catch bugs early, document how the code works, and make refactoring safer.<\/p>\n\n\n\n Unit tests can also be used with Test-Driven Development (TDD)<\/strong>. The idea is simple:<\/p>\n\n\n\n In TDD, even a compilation error counts as a failure. For example, if you\u2019re testing a class named OrderController, your first test will fail immediately because the class doesn\u2019t exist yet. This forces you to define it, guiding the development process step by step.<\/p>\n\n\n\n Why use unit tests?<\/strong><\/p>\n\n\n\n However, unit tests can become a burden when doing major refactoring. Since they\u2019re tightly coupled to implementation details, you might spend more time fixing tests than improving the actual code. That\u2019s why, for this refactoring, we\u2019ll take a different approach.<\/p>\n\n\n\n Integration tests verify the behavior of an entire service, including its interactions with external components such as databases, service buses, and distributed caches.<\/p>\n\n\n\n A common example is, when developing a .NET Web API, an integration test ensures that the entire pipeline, from the HTTP request to the controller, including AspNet middleware, works correctly.<\/p>\n\n\n\n In our case, OrderService.Api<\/a> requires a significant refactor. As mentioned earlier, writing unit tests in this scenario could be more of a burden than a benefit. However, since OrderService.Api<\/em> is already in production, we must<\/strong> ensure that its external behavior, particularly its public contracts (REST APIs), remains unchanged during the refactoring process.<\/p>\n\n\n\n This is where integration tests<\/strong> excel. Rather than testing internal implementation details, we test OrderService.Api<\/em> through its public contracts, ensuring it behaves correctly from the outside. The process can be summarized as follows:<\/p>\n\n\n\n With integration tests, we treat OrderService.Api<\/em> as a black box<\/strong>, focusing solely on its external behavior. This allows us to confidently refactor the internal implementation while ensuring that the service continues to function as expected.<\/p>\n\n\n\n Here the libraries used in the OrderService.Api example to write OrderService.Api.Integration.Tests<\/a><\/p>\n\n\n\n Using TestContainers for .NET<\/a>, we can spin up a lightweight test environment for our integration tests.<\/p>\n\n\n\n Our integration tests are built using XUnit<\/a>, which provides a mechanism to share context between tests: Fixtures<\/a>. In this case, the shared context is the test environment itself.<\/p>\n\n\n\n To achieve this, we create a Class Fixture<\/strong> that ensures all test cases in a class use the same test environment. This fixture will:<\/p>\n\n\n\n Integration Test Fixture<\/strong><\/p>\n\n\n\n The IntegrationTestFixture manages the lifecycle of the test environment. It initializes the SQL Server container<\/strong> and the OrderService API<\/strong> instance.<\/p>\n\n\nWhere we begin<\/h2>\n\n\n\n
The importance of Tests<\/h2>\n\n\n\n
Unit tests<\/h2>\n\n\n\n
\n
\n
Integration tests<\/h2>\n\n\n\n
\n
Essential .NET libraries for Integration Tests<\/h2>\n\n\n\n
\n
Setup test environment<\/h2>\n\n\n\n
\n
\n\n\n\nnamespace OrderService.Api.Integration.Tests.Fixtures;\n\npublic sealed class IntegrationTestFixture : IAsyncLifetime\n{\n public OrderServiceFixture? OrderServiceFixture { get; private set; }\n public HttpClient? Client { get; private set; }\n public SqlServerFixture SqlServerFixture { get; }\n \n \n public IntegrationTestFixture()\n {\n SqlServerFixture = new SqlServerFixture();\n }\n\n public async Task InitializeAsync()\n {\n await SqlServerFixture.InitializeAsync();\n OrderServiceFixture = new OrderServiceFixture(SqlServerFixture.GetConnectionString()); \n Client = OrderServiceFixture.CreateClient();\n }\n\n public async Task DisposeAsync()\n {\n await SqlServerFixture.DisposeAsync();\n await (OrderServiceFixture?.DisposeAsync() ?? ValueTask.CompletedTask);\n Client?.Dispose();\n }\n}\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n