DEV Community: Caio Ragazzi

Mastering Angular Templates

Caio Ragazzi — Mon, 05 Feb 2024 20:27:28 +0000

Hello Devs,

If you're an Angular developer, chances are you've worked with PrimeNG. I've been using it for some time, and there's always been one aspect that caught my attention: TEMPLATES!

Take, for instance, the PrimeNG Card component. This component provides a header property where you can pass a string, but the real power lies in customizing the header to your liking using a pTemplate. It functions as illustrated below:

<p-card header="Car Header">
    <ng-template pTemplate="header">
        <img alt="Card" src="http://fake.url.png" />
    </ng-template>
</p-card>

That's pretty awesome, right?
If you're as curious as I am, you probably want to dive into the inner workings of this template feature. No worries, my friend – I've got your back. I've explored and figured it out, and now you can too. Here's how it works, and you'll be able to apply this strategy in your components as well.

The core idea is to capture the content inside the ng-template and render it at a specific location within our component. But not just any template – we want a specific one. In the example below, our aim is to render only the template with the directive myTemplate="header" in our component:

<my-component header="Car Header">
  <ng-template myTemplate="header">
    <button>Simple button</button>
  </ng-template>
</my-component>

First things first, let's create the myTemplate directive:

import { Directive, Input, TemplateRef } from '@angular/core';

@Directive({
  selector: '[myTemplate]',
  host: {},
})
export class MyTemplateDirective {
  @Input() type: string | undefined;

  @Input('myTemplate') name: string | undefined;

  constructor(public template: TemplateRef<any>) {}

  getType(): string {
    return this.name!;
  }
}

As we can see, it's a straightforward structural directive (more on structure directives here: Angular.io) with a single input to receive the type (in our case, "header"), and a function named getType that returns the input value (I'll explain the reason for this function later in the article).

Now, let's move on to creating the component .

import {
  AfterContentInit,
  Component,
  ContentChildren,
  QueryList,
  TemplateRef,
} from '@angular/core';
import { MyTemplateDirective } from '../my-template-directive/my-template-directive';

@Component({
  selector: 'my-component',
  templateUrl: './my-component.component.html',
  styleUrl: './my-component.component.scss',
})
export class MyComponent implements AfterContentInit {
  headerTemplate: TemplateRef<any> | undefined;

  @ContentChildren(MyTemplateDirective) templates:
    | QueryList<MyTemplateDirective>
    | undefined;

  ngAfterContentInit() {
    (this.templates as QueryList<MyTemplateDirective>).forEach((item) => {
      switch (item.getType()) {
        case 'header':
          this.headerTemplate = item.template;
          break;

        default:
          break;
      }
    });
  }
}

Let's break down this component:

1) We require a property (headerTemplate) with the type TemplateRef to store the template that is being passed to the component.
2) We need a property (templates) to store all the templates that have our custom directive assigned to them. In our case, this property is 'templates' and is decorated with @ContentChildren(MyTemplate) (you can find more about the @ContentChildren decorator Angular.io)
3) With the help of the lifecycle hook AfterContentInit (you can learn more about the AfterContentInit lifecycle hook Angular.io), we iterate over all the templates and call the function getType to retrieve only the template with the directive "header," storing it in the headerTemplate property.

That wraps up the TypeScript part of our component. Essentially, we're searching for all ng-templates with our custom directive that were passed to MyComponent and extracting only the one with the 'header' input.

Now that we have the template in the headerTemplate property, let's proceed to display it in the HTML. Take a look at the code below:

<div>
  <div>
    <div *ngIf="headerTemplate">
      <div>Template content</div>
      <ng-container *ngTemplateOutlet="headerTemplate"></ng-container>
    </div>
  </div>
  <div>--------------------------</div>
  <div>
    <div>Footer without template</div>
  </div>
</div>

It's as simple as that. By utilizing the Angular structural directive ngTemplateOutlet (you can find more information on ngTemplateOutlet Angular.io) we use an ng-container to pass our headerTemplate as input with '*ngTemplateOutlet="headerTemplate"'. This allows us to dynamically render the template within our component.

This strategy empowers us to build highly customizable and flexible components. By implementing this approach, we ensure a robust component that only renders templates specified by the custom directive. It provides a level of control and encapsulation, allowing developers to create versatile components while maintaining a clear structure and limiting the rendering scope to specific templates. This can lead to more maintainable and modular code.

What are your thoughts on this design?
In what ways could this design be improved or extended?

If you want to explore the code for this example, you can find it in the GitHub repository: Angular Templates GitHub Repository.

Thank you so much for reading this post, everyone! As always, I wish you happy coding!

See you!

Comprehensive Unit Testing: A Line-by-Line Approach

Caio Ragazzi — Mon, 11 Sep 2023 20:25:07 +0000

Hello Dev's,

I hope you are having a wonderful day.

In this article, I'd like to share my recent approach to unit testing. I believe this method is highly effective in testing my classes and ensuring comprehensive coverage of my business rules. Additionally, I hope this article can provide you with valuable insights or even an opportunity to exchange tips and ideas for improving our testing practices.

Before we dive into the specifics, let me introduce the tools that will be used in this example. (Perhaps in the future, I can create a separate article dedicated to explaining why I prefer these tools):

xUnit -> https://xunit.net/
AutoFixture -> https://autofixture.github.io/
FluentAssertions -> https://fluentassertions.com/
AutoMock -> https://github.com/automock/automock

Method being tested

Let's take a simple example of a method that adds an entity to a database. Typically, this method might look something like this:

public async Task<BeerDtoResponse> AddBeer(BeerDtoRequest beerDtoRequest)
{
    var beer = _mapper.Map<Beer>(beerDtoRequest);
    beer.Id = Guid.NewGuid();

    await _beerRepository.Insert(beer);

    return _mapper.Map<BeerDtoResponse>(beer);
}

A straightforward method that maps a request DTO to an entity, adds a GUID to the ID, inserts it into the database, and returns a mapped DTO.

Objective

My primary objective is to comprehensively test every line of the method, a practice I affectionately call "Shielding the Method." Why do I adhere to this principle? Quite simply, if I've written a particular line of code, it's because it serves a purpose, and I want to ensure that it continues to function as intended. Furthermore, whenever we introduce new features or make changes, our tests must evolve in sync with the codebase to maintain its integrity.

How do I do it?

To achieve this level of comprehensive testing, I typically begin by creating a base class that houses commonly used methods. I leverage the power of AutoMock and AutoFixture to streamline this process. Here's a glimpse of what this base class might look like:

public class BaseTest
{
    private readonly Fixture _fixture = new();
    protected readonly AutoMocker _mocker = new();

    protected T CreateFixture<T>()
    {
        return _fixture.Create<T>();
    }

    protected IEnumerable<T> CreateManyFixture<T>(int count)
    {
        return _fixture.CreateMany<T>();
    }
}

A straightforward class that provides you with an instance of AutoMocker and methods to create fixtures.

Testing

Alright, then my initial approach involves creating a test method that successfully runs the AddBeer method without encountering any errors. This requires us to set up our test class correctly. Here's the reasoning behind this approach:

We need to create the service instance, generate the DTO that the method expects, set up mocking for the mapping from DTO to entity, mock the repository, and establish mocking for the mapping from entity to DTO. Let's proceed with these steps:

Configuring the test class

1) Creating the service instance:

Our AddBeer method is part of a service. Therefore, our first step is to instantiate this service for testing purposes. To streamline this process and maintain simplicity and speed, I rely on a library called AutoMock. AutoMock helps by creating an instance of the service and resolving all its dependencies. I initialize this service instance in the constructor and assign it to a global variable within the test class. This ensures that the service can be accessed by other test methods. Here's how it's implemented:

private readonly BeerService _beerService;

public BeerServiceTest()
{
    _beerService = _mocker.CreateInstance<BeerService>();
}

By using the CreateInstance method, we can specify the type for which we want to create an instance. Just like magic, this method provides us with the desired instance, complete with all of its resolved dependencies.

2) Creating the DTO:

As this DTO may be utilized by multiple test methods, I typically construct it in the constructor and assign it to a global variable within the test class. To create this DTO efficiently, I rely on AutoFixture, which simplifies the process:

private readonly BeerService _beerService;
private readonly BeerDtoRequest _beerDtoRequest;

public BeerServiceTest()
{
    _beerService = _mocker.CreateInstance<BeerService>();
    _beerDtoRequest = CreateFixture<BeerDtoRequest>();
}

In this context, we are making use of a helper method from the base class, which utilizes AutoFixture to generate instances of the required classes. We achieve this by invoking the AutoFixture method Create.

3) Mocking the first map (DTO to entity)

To mock the mapping method, we also leverage AutoMock. This can be accomplished by invoking the GetMock method and then configuring the Setup and Return as follows:

_beer = new Beer
{
    Name = "Beer",
    Brand = "Brand",
    Score = 1,
    User = "User"
};
_mocker.GetMock<IMapper>().Setup(m => m.Map<Beer>(_beerDtoRequest)).Returns(_beer);

In this step, it's crucial to create the beer entity and assign it to a global variable within our test class. This entity will be used in future assertions, making it an essential part of our testing setup.

4) Mocking the repository

We will apply the same concept here as in step 3, utilizing AutoMock and configuring the Setup. The only difference is that we don't need to configure the Return because our repository method Insert does not return anything:

_mocker.GetMock<IBeerRepository>().Setup(m => m.Insert(_beer));

5) Mocking the other map (entity to DTO)

Similar to step 3, we'll once again employ AutoMock, configuring the Setup and Return. Of course, we also need to create an instance of our response, for which we can utilize AutoFixture and assign the result to a global variable:

_beerDtoResponse = CreateFixture<BeerDtoResponse>();
_mocker.GetMock<IMapper>().Setup(m => m.Map<BeerDtoResponse>(_beer)).Returns(_beerDtoResponse);

Here's how the constructor and variables will look like in their final form:

private readonly BeerService _beerService;
private readonly BeerDtoRequest _beerDtoRequest;
private readonly BeerDtoResponse _beerDtoResponse;
private readonly Beer _beer;

public BeerServiceTest()
{
    _beerService = _mocker.CreateInstance<BeerService>();
    _beerDtoRequest = CreateFixture<BeerDtoRequest>();

    _beer = new Beer
    {
        Name = "Beer",
        Brand = "Brand",
        Score = 1,
        User = "User"
    };

    _mocker.GetMock<IMapper>().Setup(m => m.Map<Beer>(_beerDtoRequest)).Returns(_beer);
    _mocker.GetMock<IBeerRepository>().Setup(m => m.Insert(_beer));

    _beerDtoResponse = CreateFixture<BeerDtoResponse>();
    _mocker.GetMock<IMapper>().Setup(m => m.Map<BeerDtoResponse>(_beer)).Returns(_beerDtoResponse);
}

That's it, now we have our method ready to be used. Lets start writing our test methods.

First test "happy path"

As mentioned earlier, for the first test method, I typically ensure that no exceptions are thrown, often referred to as navigating the "happy path." The method is structured like this:

[Fact]
public async Task ItShouldRunWithoutErrors()
{
    Func<Task> act = () => _beerService.AddBeer(_beerDtoRequest);
    await act.Should().NotThrowAsync();
}

Let's break down what's happening in this code:

We start by invoking our AddBeer method using the service instance we created with AutoMocker, and we assign the result to a Func.
We utilize FluentAssertion to verify that our function executes without throwing any errors. This is achieved by chaining the methods Should() and NotThrowAsync().

When we run dotnet test from the command line, we can observe that our first test passes successfully.

Indeed, we've made significant progress. We now have a callable method that is functional. Our next task is to ensure that every line of our AddBeer method remains intact. If any changes are made, our test methods should break and alert the developer that corrective actions are required. This will help us maintain code integrity and ensure that future modifications are thoroughly tested.

Testing line by line

For this, let's go line by line in the AddBeer method:

1) First Line:

var beer = _mapper.Map<Beer>(beerDtoRequest);

To ensure that the first line, where we map the DTO request to an entity, is consistently used with AutoMapper and the same DTO request, we can employ AutoMock. We can use the Verify method and configure it to assert that the method is called with specific parameters and even specify how many times it should be executed. The test method would be structured like this:

[Fact]
public async Task ItShouldMapBeerDtoRequestToBeer()
{
    await _beerService.AddBeer(_beerDtoRequest);

    _mocker.GetMock<IMapper>().Verify(m => m.Map<Beer>(_beerDtoRequest), Times.Once);
}

In the Verify method, the first parameter specifies how we expect the method to be called, and the second parameter indicates how many times it should be executed. This allows us to precisely define the expected behavior of the method being tested.

-- Here's the interesting part --

Imagine someone decides to refactor the AddBeer method and opts to manually perform the mapping instead of using AutoMapper, something like this (for the sake of example):

The AddBeer method might still work after the refactoring, but the reason we initially chose to use AutoMapper may be due to specific profile configurations or other factors that could potentially alter the method's behavior. However, with our test in place, let's observe what happens when we execute it:

The test result clearly indicates that the AutoMap.Map method was expected to be called, but it wasn't, which is indeed valuable feedback for maintaining the integrity of our code.

Let's continue with the examination of the AddBeer method.

2) Second Line:

beer.Id = Guid.NewGuid();

In the line where we assign a GUID to our mapped entity's ID property, we can create a test method to ensure that this line is always executed. Here's an example of how such a test method could be structured:

[Fact]
public async Task BeerIdShouldHaveAGUIDAssigned()
{
    await _beerService.AddBeer(_beerDtoRequest);

    _beer.Id.Should().NotBeEmpty();
}

In this test method, we begin by invoking our AddBeer method and subsequently verify that _beer.Id is not empty using the FluentAssert methods Should() and NotBeEmpty().

This approach serves as an effective safeguard. If, during a refactoring process, someone forgets to assign the GUID, our test method will promptly raise an issue, ensuring that the critical aspect of our code is not overlooked.

3) Third line:

await _beerRepository.Insert(beer);

For testing the line where we call the repository and insert our entity into the database, we can utilize the AutoMock library to verify that the Insert method is invoked with the desired parameter and the correct number of times. Here's an example of how such a test method could be structured:

[Fact]
public async Task ItShouldInserBeer()
{
    await _beerService.AddBeer(_beerDtoRequest);

    _mocker.GetMock<IBeerRepository>().Verify(m => m.Insert(_beer), Times.Once);
}

If someone accidentally removes this line from our AddBeer method, our test will promptly identify the omission and trigger an exception. This acts as a safety measure against unintentional code alterations or deletions.

4) Fourth and last line

This line provides an opportunity to create multiple tests. We can use it to verify:

Whether the mapping is executed correctly.
If the return type matches our expected type.
The contents of the DTO being returned.

By segmenting these aspects into separate tests, we can thoroughly assess the functionality of this line in our AddBeer method.

[Fact]
public async Task ItShoulMapBeerDtoResponseToBeer()
{
    await _beerService.AddBeer(_beerDtoRequest);

    _mocker.GetMock<IMapper>().Verify(m => m.Map<BeerDtoResponse>(_beer), Times.Once);
}

[Fact]
public async Task ItShouldReturnTypeBeerDtoResponse()
{
    var result = await _beerService.AddBeer(_beerDtoRequest);

    result.Should().BeOfType<BeerDtoResponse>();
}

[Fact]
public async Task ItShouldReturnBeerDtoResponse()
{
    var result = await _beerService.AddBeer(_beerDtoRequest);

    result.Should().Be(_beerDtoResponse);
}

For these tests:

To ensure that the mapping is executed, we employ the AutoMock Verify method as we did previously, validating that the Map method is called once.
For type validation, we use FluentAssertion's BeOfType method to confirm that the return type matches our expected type.
To verify that the returned beer matches our expectations, we use FluentAssertion's Be method.

Conclusion:

When I approach testing a method, I follow a systematic approach where I create one test method for each line of the method being tested, adhering to the Single Responsibility Principle (SRP). Additionally, I often create one test class for each method I want to test. For instance, if a service class contains four methods (representing simple CRUD operations), I'll likely have four test classes, each dedicated to one method.

I usually start my tests by creating a basic test that runs the method under test and ensures it doesn't throw any errors. Afterward, I meticulously test each line of the method, as we've explored earlier.

When it comes to naming my test methods, I aim for maximum specificity. I don't worry about the length of the name; instead, I want it to clearly explain what the method is testing, and I stick to testing just one thing per method.

As you can see, we were able to create seven test methods for a straightforward AddBeer function, which aligns perfectly with the goal of unit testing. The aim here is to have as many tests as possible for a single unit, ensuring comprehensive coverage and robust validation.

I hope this approach proves helpful to you in your testing efforts. If you have any insights or feedback to share, please feel free to do so.

Wishing you a fantastic day!

.NET + Secret Manager

Caio Ragazzi — Sun, 03 Sep 2023 08:15:04 +0000

Hello again, fellow developers!

What a beautiful Sunday to dive into the topic of security! I understand that many of you are in the process of developing fantastic .NET applications with a myriad of integration services like Google Cloud Platform, databases, APIs, and more. Each integration brings its set of keys, passwords, and sensitive information, all residing in your appsettings.json file, just waiting for the wrong hands to get hold of them, potentially compromising your integrations and security.

Imagine this scenario: you've just completed an incredible feature and are eager to push it to your public GitHub repository. But then, a moment of panic hits you as you remember that your appsettings.json contains sensitive data. You can't risk exposing it to the public. So, you're faced with the tedious task of scrubbing your configuration clean before publishing. And to make matters worse, every time you start working again, you must reconfigure everything or maintain a separate copy of your appsettings on your local PC.

But fear not, my friends, for the Microsoft team has come to the rescue with something truly remarkable: user secrets.

What is it?

Dotnet user secrets is a command-line tool that securely stores sensitive data in a separate location from your project. The beauty of it is that you can easily access this sensitive information without needing to make any changes to your project itself. Intrigued?

How does it work?

Setting up user secrets is incredibly straightforward, I can assure you! To get started, all you need to do is run the init command within your project folder.

dotnet user-secrets init

After running the init command, you'll notice that your .csproj file will have a UserSecretsId element inside the PropertyGroup, something along these lines:

<PropertyGroup>
  <TargetFramework>netcoreapp3.1</TargetFramework>
  <UserSecretsId>79a3edd0-2092-40a2-a04d-dcb46d5ca9ed</UserSecretsId>
</PropertyGroup>

Once you've initiated user secrets, you can start adding your "secrets." To add a new secret, use the set command, and make sure to include a key-value attribute like this:

dotnet user-secrets set "ConnectionString" "XYz"

We can consider secrets as similar to our AppSettings.json. For instance, let's say we have the following item configured in it:

You can effortlessly execute the following commands to store the two connection strings in our secrets vault:

dotnet user-secrets set "ConnectionStrings:MySql" "server=127.0.0.1;uid=root;pwd=12345;database=test"

dotnet user-secrets set "ConnectionStrings:SQL" "Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;"

As we can see, we have literal objects in our key-value pairs. In this example, we define two different properties (MySQL and SQL) with distinct values.

After configuring these key-value pairs, you could completely remove the ConnectionStrings section from the AppSettings, and your code would still function seamlessly. Isn't that amazing?

Now that you've added your secrets to your vault, you might wonder how to access them. Well, the beauty of it is that it doesn't change the way you access your AppSettings. You can still inject the IConfiguration interface into your class and access it in the same familiar way.

You could achieve a similar outcome by adding your keys to environment variables, but with the dotnet user-secrets tool, everything becomes more convenient and streamlined for our day-to-day tasks.

It's pretty awesome, right? If you want to dive deeper into this tool, you can find more information here:

https://learn.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-7.0&tabs=linux

There are many more features described that can be incredibly useful for you.

For now, that's all, my friends. I hope you're having a fantastic day!

Keep coding, and I'll see you around!

Google Storage + .NET 7

Caio Ragazzi — Tue, 15 Aug 2023 19:59:38 +0000

Hello, fellow dev friends. I hope you all are doing great.

When I am writing this article is a national holiday here in Portugal (Assumption of Mary) 🇵🇹 and how to enjoy most of this beautiful day? Going to the park? beach? eat some delicious pastries? Not at all! Let's write my first (yesss that's it, my first!) post here at dev.to!

Being a Brazilian leaving in Portugal is quite easy, to be honest (mostly because of the language), but writing here for developers all over the world, well, this can be a bit tricky for me! But let's try it out!
Enough of introductions and let's start talking about what is actually saying in the title!

In the last few days, I have started learning some Google Cloud concepts through https://www.cloudskillsboost.google/ (by the way, such an amazing platform to learn GCP). And one of the first concepts they teach us is Google Cloud Storage. And for me, the best way to learn those concepts is by applying them in a practical way.

So First I created a really small .NET 7 Class Library to upload some files in Cloud Storage Bucket.

Let's start by creating a new Class Library project. Here I am using the C# Dev Kit extension for Visual Code to keep things simple (I could also use the dotnet CLI):

What is cool about the C# Dev Kit is that when you create a Class Library in an empty folder it also creates the solution for you:

Here is where things really got me excited, because I thought the process to import a file to the GCP Cloud Storage would be a bit complex, but it is actually not.

⚠️ Before we continue is important to go through the following steps:

We need to authenticate our application in the GCP by using the Application Default Credentials or commonly known as ADC. There are a couple of ways of doing it but for me, the easier is by using the gcloud CLI:

gcloud auth application-default login

If you want to know more about the command above, you can visit the URL:

https://cloud.google.com/sdk/gcloud/reference/auth/application-default/login

But basically, you will need to follow some steps to obtain user access credentials and then the CLI will place it in a location where the ADC will get it.

Now we can start configuring our project. We will need to install the Google Cloud Storage V1 Nuget Package:

https://www.nuget.org/packages/Google.Cloud.Storage.V1

And then with a couple of lines, we can easily upload files to buckets in Google Cloud:

public class FileUploader
{
    public async Task<string> UploadFile(string base64String)
    {
        var client = await StorageClient.CreateAsync();

        var bucket = await client.GetBucketAsync("bucket name");

        var bytes = Convert.FromBase64String(base64String);
        var dataObject = await client.UploadObjectAsync(bucket.Name, "folder/fileName.png", "text/plain", new MemoryStream(bytes));

        return dataObject.Id;
    }
}

Let's go through line by line to see what is happening:

var client = await StorageClient.CreateAsync();

First, we use this static method CreateAsync to get an instance of the class StorageClient.

var bucket = await client.GetBucketAsync("bucket name");

Here we are getting an instance of an existing bucket by its name, but if you don't have a bucket yet, you could create a new one using the method CreateBucketAsync which will also return a bucket instance.

var bytes = Convert.FromBase64String(base64String);

Then we are getting a little help from the method FromBase64String to convert a "probably" base64 photo to an array of bytes.

var dataObject = await client.UploadObjectAsync(bucket.Name, "folder/fileName.png", "text/plain", new MemoryStream(bytes));

And to finally upload the file, we pass three parameters to the method UploadObjectAsync

Bucket Name.
File Name (But here you could also organize your bucket with folders by passing the folder name in the string like this "folder1/folder2/filename.png").
Stream - and that's why we had to convert our base64 string to an array of bytes!

return dataObject.Id;

And finally, here I just returned the Id of the newly created object, which is basically the ID of the object, including the bucket name, object name, and generation number.

And that's it, incredible isn't it? With a small effort, we can create a method that will upload some files to a GCP Bucket.

Thanks a lot, guys! I will try to post more content here so please tell me what you think about this post and if you are in a good day tell me how can I improve it 😄!

Now I can come back to the holiday and eat some delicious pastries that only Portugal can give to us 🍪 🍰! If you have been here you know what I am talking about (Pastéis de Nata)