DEV Community: Erikvdv

Revolutionizing UI Development in DotNet with Ui Mock

Erikvdv — Mon, 08 Jan 2024 20:24:41 +0000

The need for speed, efficiency, and adaptability in UI development in .Net has never been greater, and I am thrilled to introduce you to my new (and very first) library, Dotnet UI Mock.

The above video provides a quick demonstration of the library's capabilities, particularly its proficiency in swiftly iterating between multiple mocked scenarios to validate the behavior of your .Net application's UI.

While working with single-page applications, I've frequently utilized libraries like WireMock and ngApiMock to mock my backend REST API endpoints. However, while developing your frontend in .Net, you might encounter multiple dependencies you'd want to mock, such as databases, REST APIs from different services, GRPC services, SOAP services, etc. Achieving a similar developer experience as with Single Page Applications often felt challenging.

Dotnet UI mock (github) is a solution to this challenge, extending this streamlined experience to .Net UI development.

You can find an example that demonstrates the use of this library in the GitHub repository. The results are displayed in the demo video above.

In the demo, I initiate the sample using the dotnet watch command:
dotnet watch --project=sample

The world of UI development in .Net is rapidly evolving, with an increasing demand for speed, efficiency, and adaptability. Recognizing these needs, I am excited to present my first-ever library, Dotnet UI Mock.

During my journey working with single-page applications, I've frequently utilized libraries like WireMock and ngApiMock to mock my backend REST API endpoints. However, while developing your frontend in .Net, you might encounter multiple dependencies you'd want to mock, such as databases, REST APIs from different services, GRPC services, SOAP services, etc. Achieving a similar developer experience as with Single Page Applications often felt challenging.

Dotnet UI Mock (github) is a solution to this challenge, extending this streamlined experience to .Net UI development.

You can find an example that demonstrates the use of this library in the GitHub repository. The results are displayed in the demo video above.

In the demo, I initiate the sample using the dotnet watch command:
dotnet watch --project=sample

This command automatically detects changes in the mock setting and refreshes the UI, which in this case, is built with Blazor.

Creating a list of mocks is quite simple with Dotnet UI Mock. In its initial implementation, I've chosen Nsubstitute as the preferred mocking library (currently, it's the only supported mocking library). This powerful tool is set to revolutionize the way you approach UI development in .Net.

public class WeatherServiceMock : BaseMockService<IWeatherService>
{
    public WeatherServiceMock()
    {
        MethodMocks =
        [
            new("GetForecastAsync",
            [
                new MockScenario("oneitem", GetForecastOneItem),
                new MockScenario("threeitems", GetForecastThreeItems),
                new MockScenario("exception", GetForecastAsyncException),
            ], 200),
            new("GetForecastAsync(string location)",
            [
                new MockScenario("withlocation", GetForecastWithLocation),
                new MockScenario("exception", GetForecastWithLocationException),
            ], 100),
        ];
    }

    private static void GetForecastOneItem(object service, int delay)
    {
        (service as IWeatherService)?.GetForecastAsync().Returns(async _ =>
        {
            await Task.Delay(delay);
            return new WeatherForecast[]
            {
                new() {Date = new DateOnly(2021, 1, 1), TemperatureC = 10, Summary = "Freezing"}
            };
        });
    }

    // removed other scenarios
}

To wrap up this post, let's highlight some key features of the Dotnet UI Mock library:

Swift iteration between multiple mocked scenarios: This allows you to validate various scenarios without spending significant time on setup.
Switching to the original implementation: If you need to compare the mock with the original or just revert to the actual functionality, Dotnet UI Mock makes this a breeze.
Automatic UI refresh with dotnet watch: With this feature, you can see the impact of your changes immediately, enhancing productivity and reducing debugging time.
Mocking application authentication: This feature, detailed in the sample, adds another layer of flexibility to your testing approach.

I am genuinely excited to hear your thoughts and feedback on this new library! Your insights can help make Dotnet UI Mock an even more potent tool for the .Net community. Feel free to share your experiences, suggestions, or questions. Let's collaborate and make .Net UI development more efficient and enjoyable!

Creating a realworld app with C# dotnet

Erikvdv — Sat, 23 Jul 2022 14:28:44 +0000

Once in a while I create a realworld app (demo) to learn a new framework or explore certain different ways of application architecture.

After experimenting with several frameworks to implement the frontend, this time I decided to create the backend. I used C# .Net for this.

My code can be found here

Recent years I have been using this stack extensively and this time, next to experimenting a bit, I aimed to create a clean reference that I would be able to refer to when creating future solutions.

The key things I like about implementing a real world app are reading about best practices and implement them in an elegant way and experimenting with some concepts/libraries that might help with that.

The solution

For the solution I opted for a fairly traditional clean architecture setup using .Net 6.
The solution consists of the following layers:

api (wires up the solution and defines the api endpoints)
core (contains the core business logic)
data (contains the interaction with the DB)
infrastructure (generic code that potentially could be used in different solutions)

And I used the following features:

the new WebApplication.CreateBuilder(args)
file scoped namespaces
global usings
Entity Framework Core with SQLite db
serilog for logging, integrated with application insights, including realtime monitoring
Hellang.Middleware.ProblemDetails for consistent error output
sonarlint for code scanning

Justification of choices and Retrospective

Within the remainder of this post I will reflect on the choices I made.

Application layering

using distinct projects for this specific implementation is not required within this application. However, it makes it more clear where specific responsibilities should be.
Api Layer: I have considered using the .Net 6 minimal api's. However, I do think at this moment it is a bit too early as they are still lacking features (e.g. api grouping, model validation). I could have used something like Carter, but it relies on FluentValidation, which I always find hard to debug. I prefer something like this that is easy to debug and understand.
I have doubted if I should combine the Core and Data layer into a single layer. As I am using Entity Framework in the data layer, the core layer (or at least the developer) actually needs to be aware of the EF concepts. The benefit of the current split is that it is easier to validate the database interaction (as can be seen here) and that the services in the core layer are easier to unit test as the repository can easily be mocked)

Features

I do like the the WebApplication.CreateBuilder(args) that is new in .Net 6. It is easier to just have a program.cs file where both the host, the services and request pipeline is configured, instead of having a separate Startup file as well. For bigger projects I do expect one would like to structure the program.cs file a bit more as it could become hard to navigate
file scoped namespaces: even being small, in my view this is a huge improvement that came with .Net 6 in terms of readability. Personally I would even like to have the option to go "namespaceless" by just taking the folder structure and a rootnamespace defined in the csproj file as the namespace.
global usings: Don't see a lot of benefits here, while developing I manually needed to move stuff that is normally just handled by my IDE.
serilog: I do like serilog for logging, however the integration with Application Insights is limited to log events as events or as traces, which prevents requests to be logged as requests in AI.
Hellang.Middleware.ProblemDetails really works well for me. It makes it very easy to add a global exception handler that allows for consistent responses for all types of problems, whether they are technical or functional and works well with the .Net default ApiController problem details response for model validation.
sonarlint for code scanning: I do think this is beneficial mainly to keep a consistent code style in your project (together with the other config in .editorconfig)

Conclusion

I can recommend anyone to build a realworld app. It really encourages you to dive deeper in a language/framework than what you would to in your typical todo app tutorial.
If you are more familiar with a language/framework it allows you to experiment with architectures you are less familiar with.
Besides that, when you like solving puzzles like me, your time is definitely more valuable spend than on solving Sudoku's ;).

Looking specifically at this C# .Net implementation it might help you to think about how to practically structure your application