DEV Community: Pedro Osternack Corrêa

Customizing AutoFixture to simplify our tests setups

Pedro Osternack Corrêa — Tue, 03 Jan 2023 01:08:17 +0000

On a previous post I've showed how to register an implementation for an interface to be used by AutoFixture. We can simplify that a bit by adding customizations to our AutoFixture instance.

Let's say that we have the following test method:

public void TestOne()
{
    var fixture = new Fixture();

    // registering our interface implementation.
    fixture.Register<IConverter<Type1, Type2>>(() => new T1toT2Converter());

    var sut = fixture.Create<ServicyMcServiceFace>();
}

We can an AutoFixture customization by implementing the ICustomization interface and passing said implementation to our fixture object.

Let's create a customization that will register our IConverter implementation for us so we don't need to do that on the test:

// Our customization
public class ConverterCustomization : ICustomization
{
    // the method declared by the ICustomization interface
    public void Customize(IFixture fixture)
    {
        fixture.Register<IConverter<Type1, Type2>>(() => new T1toT2Converter());
    }
}

Now we can refactor our test method to use that customization.

public void TestOne()
{
    var fixture = new Fixture().Customize(new ConverterCustomization());

    var sut = fixture.Create<ServicyMcServiceFace>();
}

Because of our customization every time we use that fixture instance to create an object that needs an instance of IConverter<Type1, Type2>, said object will receive an instance of T1toT2Converter, the same as before.

This pattern can be very useful for complex domains with lots of interfaces or if we want to provide some rules for the creation of our objects in a clean and easily reusable manner.

TIL: You can await a promise with callbacks.

Pedro Osternack Corrêa — Thu, 03 Feb 2022 23:51:41 +0000

I was working on some code and saw the following:

await somePromise
    .then(/* doing something with the resolved value*/)
    .catch(/* handling errors*/);

I need to admit that it took me a while to understand what was happening there.
After that moment of surprise I went to the MDN Docs on promises and finally understood what was going on there.
My main surprise came from the habit of either using the callback style of the async/await one, but never mixing both. To be honest when async/await became official I've seldom used the callback notation again.
So a bit of context, a ton of Promise methods return a Promise. That's what enables us to chain .then() calls or have something like .then().catch().finally(). Which of these methods returns a new Promise.
Async/Await is basically a bit of syntax sugar for deal with Promises. Async functions are functions that return a Promise. Await (in a simplified way) allows us to handle a Promise being resolved in another way without needing the .then() callback.

let value = await somePromise;
// is the same as
let value;
somePromise.then((v) => value = v);

But as I've alluded to before, the then, catch and finally methods return each a new Promise. So, since async/await is just syntax sugar for promises, we can mix and match both notations.
Here are some examples:

requestPromise
    .then((resp) => resp.data)
    .then((data) => updateState(data))
    .catch((err) => console.error(err))
    .finally(() =>  console.info("we're done here"));

// --------------------------
// Is the same as
// --------------------------

try {
    const resp = await requestPromise;
    await updateState(resp.data);
} catch (err) {
    console.error(err);
} finally {
    console.info("we're done here")
}

// --------------------------
// Or even
// --------------------------

// assuming only this method will throw an error.
// if it throws, resp will be undefined
const resp = await requestPromise
    .catch((err) => console.error(err));

if (resp) {
    await updateState(resp.data);
}

console.info("we're done here")

// --------------------------
// Or we can just await for the whole thing in a async function
// --------------------------

await requestPromise
    .then((resp) => resp.data)
    .then((data) => updateState(data))
    .catch((err) => console.error(err))
    .finally(() =>  console.info("we're done here"));

It's an interesting pattern that honestly I never though about until now and I found it curious. I'm not 100% sure if I will mix and match the styles like this, I think it may become a bit confusing, at least while you're not used to it.
I can see the appeal of having the catch without the try block, but again, not 100% sold on it. Probably time will tell.
So, what do you think? Is this a pattern you've seen before? Is this something that you actively use? If so, in what contexts? If not would you use this mixing pattern?

Creating variables dynamically in Powershell

Pedro Osternack Corrêa — Tue, 04 Jan 2022 22:24:09 +0000

This is the first part of my "Being lazy with PowerShell" series were I'm documenting my exploration of the language by solving some simple problems. If want more context on what we're doing here please check the introduction post here.

TL; DR;

Here's the final snippet for this post.

$reposFolder = "C:\repos\"
$repos = @{
    client = "client-portal";
    dash = "service-dashboard";
    users = "users-api-v4";
    devops = "devops-toolkit";
    main = "backend-monster";
    data = "data-bridge";
}

$repos.Keys | ForEach-Object { New-Variable -Name $_ -Value ($reposFolder + $repos[$_])}

This will generate one variable on the local scope of your PowerShell session for each entry on the $repos HashMap, and you can use them to easily navigate to the repo folders like this: cd $client.
If you want a more in-depth explanation of what's going on just keep scrolling :D.

Initial Setup

My first attempt is kind of simple, I'll create a new variable for each repo that I have, but I want to do that programmatically.
The first step was to create a HashMap with all the repos. On one hand I could list my repos folder and go from there, but the HashMap approach gives me the option of defining a key for each folder and use that as the variable name. Also I'm getting started so want to keep the logic very as light as possible.

So, this is what my repos folder looks like:

PS C:\repos> ls


    Directory: C:\repos


Mode                 LastWriteTime         Length Name                                                                                                                                                                               
----                 -------------         ------ ----                                                                                                                                                                               
d-----        2021-12-14   8:52 PM                backend-monster                                                                                                                                                       
d-----        2021-12-14   8:52 PM                client-portal                                                                                                                                                           
d-----        2021-12-14   8:52 PM                data-bridge                                                                                                                                                               
d-----        2021-12-14   8:52 PM                devops-toolkit                                                                                                                                                              
d-----        2021-12-14   8:52 PM                service-dashboard                                                                                    
d-----        2021-12-14   8:52 PM                users-api-v4

Based on that I've created the following HashMap:

$repos = @{
    client = "client-portal";
    dash = "service-dashboard";
    users = "users-api-v4";
    devops = "devops-toolkit";
    main = "backend-monster";
    data = "data-bridge";
}

Here I've mapped each one of my repos to a key that identifies them and that I'll use to identify my variables, such that the client-portal should be the value of the variable $client portal, and so on.

Building the script

Now that we have a map we need to iterate over my $repos map, for that end we can use either the HashMap ForEach method or the ForEach-Object cmdlet, I'll use the latter here, but they'll give us the same results. (there are more ways of solving this problem and I'll list the ones that I know at the end just as a curiosity)
Now, you cannot iterate over a HashMap in PowerShell the same way you can over an Array. By that I mean that if we just use the following command we will only see "Hello" printed once on our terminal.

$repos | ForEach-Object { "Hello" }

To be able to iterate over each item we can use either $repos.Keys to get each key of the map or $repos.Values to get each value of the map. So if we update the snippet above to use the Keys property, we should see Hello being printed once for each item on the map (6 times in this case).

$repos.Keys | ForEach-Object { "Hello" }

Ok, let's step back for a bit. What's happening on the snippet above is: we're evaluation $repos.Keys which will return each key on our map to the console, and passing that result to the ForEach-Object cmdlet using the pipe operaton |. That ForEach-Object cmdlet will print Hello for each item returned by the previous command ($repos.Keys in this case).
What is the difference between both snippets then? On the first one, evaluating $repo will return only one result, which will be the full map, so the ForEach-Object will only have 1 entry to work with. On the other hand, $repos.Keys will not return the list of keys, but each key inside of that list, which means that the ForEach-Object will receive 6 entries. Interesting, right?

Moving on. We can iterate over the keys of our map, and now we want to use them. to do so we can use the $_ variable. That is a special variable that powershell gives us so we can get current item being iterated over inside of the foreach loop. So, if we update our snippet again we will see all keys being printed on our console.

PS C:\repos> $repos.Keys | ForEach-Object { $_ }
dash
data
devops
client
users
main

Ok, good, from here we need to access the value for those keys. To do so we can use them as indexes on the map like this: $repo[key]. Let's update the snippet once again.

PS C:\repos> $repos.Keys | ForEach-Object { $_ + " -> " + $repos[$_] }
dash -> service-dashboard
data -> data-bridge
devops -> devops-toolkit
client -> client-portal
users -> users-api-v4
main -> backend-monster

Now all we need to do if define our new variables. The easiest way I could find to do that is by using the New-Variable cmdlet. We can than pass our key as the -Name argument and the path to the repo as the -Value argument to that cmdlet and we should be good to go. The path for the repos is a combination of the path to my repos folder (c:\repos) and the folder name in the map. The script should look something like this:

$repos.Keys | ForEach-Object { New-Variable -Name $_ -Value ("C:\repos\" + $repos[$_])}

After running the above script now we should have available on our terminal one variable for each entry on our map. We can call them by prepending $ to the key. They should look something like this

$dash -> C:\repos\service-dashboard
$data -> C:\repos\data-bridge
$devops -> C:\repos\devops-toolkit
$client -> C:\repos\client-portal
$users -> C:\repos\users-api-v4
$main -> C:\repos\backend-monster

And we can use them in combination with cd (or Set-Location if you want to get fancy) to navigate to our repos, ex.: cd $dash should send us to the C:\repos\service-dashboard directory and so on and so forth.

About the solution

This certainly works. I can have aliases for my folders and need to type less to get to my repos, but it's not there yet.
One issue is adding a new folder requires to create a new entry on the map on my posh profile. Admittedly this is not a huge issue, mainly if you consider the likeliness of adding new projects to the specific solution or how often that would happen.
Also we need to be very conscious of our variable names to not create unwanted conflicts, which may be a bigger problem if you rely on posh for your day-to-day work.
And there's also the small issue of needing to type cd $, the main problem being the $ I really want to avoid that. (Please note that this is not a problem at all, I just want an excuse to try some new stuff, so bear with me.)
So for my next attempt I'll probably try to tackle some of those points.

Well this is it for now, hope that you've liked this first post and maybe found it somewhat useful. See you on the next one.

Cover Photo by Dean Pugh on Unsplash

Being lazy with PowerShell

Pedro Osternack Corrêa — Tue, 14 Dec 2021 14:24:14 +0000

So this is a brief introduction to give some context to some posts that I want to make. I'm putting this as a its own post so I can focus on the code and solution on the next ones.

The problem

Currently I'm working on a project with several different repos and I need to switch between them constantly. Everything works well, the repos are on my c:\src folder, so navigate to them using regular methods (cd /src/repo-name-here) with a fair share of tab auto-complete is not a huge problem. But I've decide to try and make it as simple as possible, firstly because simplicity is good, second because I like the challenge and it's a good excuse to train my (fairly weak I must admit) pwsh muscles.

My idea is to be able to go to the desired folder as fast as possible regardless of where I'm on my system. Ideally having a function called repo1 that is a very simple script that will cd me to the right folder. I can surely do that by hand, create one function for each repo on my profile file and call it a day, but that's not fun :D (and doesn't scale well), so I want to create those functions programmatically (that goal may change on the future, let's see).

What's next

The idea is to do some research and incrementally enhance my solutions and I'll create new posts with my findings. I wanted to make a huge post with the whole exploration, but that would just take a long time to get done and I'd probably never finish it (:stares at the list of drafts on the dashboard:), so I've decided to try and make a series of posts and see how it goes.

See you on the next post.

P.S.:
For sure the problem is pretty simple and the solutions will probably be over-engineered, but that's the fun of this kind of exercise :D.

TIL: How to register an implementation of a generic interface in AutoFixture

Pedro Osternack Corrêa — Mon, 07 Jun 2021 23:07:55 +0000

On a previous post I've used AutoFixture with a auto mocking customization (that would generate mocks for each dependency of the system under test (SUT) that you create through AutoFixture). On that post I had one snippet that used the Register method, like this:

// Initializing each mocks manually and use AutoFixture for the SUT
private ServicyMcServiceFace CreateFixtureSemiAuto()
{
    var fixture = new Fixture();

    var dep1 = new Mock<IDependency1>();

    fixture.Register(dep1.Object);

    return fixture.Create<ServicyMcServiceFace>();
}

I did not gave muck attention to that method at the time, but recently I had to use it in a different manner so I decided to share it.
On the example above we have a service that have a service that has a dependency of type IDependency1. By registering the Mocked object with the fixture we're basically configuring it as our dependency injection (DI) container (or Inversion Of Control Container) and telling it to use that Mock every time someone asks for the IDependency1 interface. The same can be done with a real implementation of the interface, but instead of passing the mocked object we would pass a new instance of the implementing class.
So far so good.
But if we have a generic interface as our dependency that method overload will not work.

// Constructor for ServicyMcServiceFace
public ServicyMcServiceFace(IConverter<Type1, Type2> converter)
{ ... }

// The implementation or our dependency that we want to use on our test
public class T1toT2Converter: IConverter<Type1, Type2> { ... }

On this example our SUT depends the a converter between Type1 and Type2, and we want to use the T1toT2Converter implementation of that interface on our tests (there are many reasons why one would prefer to do that instead of using a mock, but this discussion if beyond the point of this post). We can easily register that with in our fixture by using one of the generic overloads of the Register method as follows.

private ServicyMcServiceFace CreateFixtureSemiAuto()
{
    var fixture = new Fixture();

    // registering our interface implementation.
    fixture.Register<IConverter<Type1, Type2>>(() => new T1toT2Converter());

    return fixture.Create<ServicyMcServiceFace>();
}

And there you go. Now every time you create a new instance of the SUT through the fixture it will receive a new instance of the converter.
If you want to use just one instance of the dependency you can just instantiate the dependency, save it to a field on your test suit and pass that in the Register callback method, for example.
The Register method is way more powerful than I make it appear here, and it gives a lot of options to customize how AutoFixture will generate your fixtures. I highly recommend reading the articles form Mark Seeman's blog that I'll add to the references at the end of this post.

So that's that for now, I hope this can be useful.

References:
Dealing With Types Without Public Constructors
Replacing AutoFixture's Default Algorithms

TIL: RxJS Observables are unicast and we can multicast them.

Pedro Osternack Corrêa — Fri, 12 Mar 2021 01:33:56 +0000

While working on an Angular + NgRx project I started to deal with RxJS Observables more and more, and with that, I've started to notice some interesting behaviours that were not making a lot of sense for me, a complete newcomer to the world of RxJS. One of them was during the debugging process on a test where I was asserting the number of times that an observable side-effect was being triggered, but I had subscribed to the observable to check the value being emitted.

// my observable
observable$ = event$.pipe(
  tap((val) => this.dataService.handleEvent(val))
);

// the test
it('should use dataService to handle the eventData', () => {
  // I've added this line for debugging purposes 
  component.observable$.subscribe((eventVal) => console.log(eventVal));

  // this was falling because the handleEvent was being called twice
  expect(mockDataService.handleEvent).toHaveBeenCalledTimes(1); 
});

I've noticed that that test started to fail when I've added my new subscription, and would start to work again when I remove that line. That's when the concept of observable being unicast finally made sense in my head. What I was seeing was the because each of my subscribers to observable$ were getting their own copy of the observable chain or Producer (think of everything inside of the observable pipe call). So since I had 2 subscribers to my observable, every time the event$ observable emitted a value, the tap on the observable$ would be called twice, one for each subscriber.

A more concrete example

Consider the following block of code:

// creating an observable that emits once every 2 seconds.
// we want to use on the 3 first values
// and every time a value is emitted we will log a random number in the console
const observable$ = interval(2000).pipe(
  take(3),
  tap(() => console.log(Math.random()))
);

observable$.subscribe(
  val => console.log(`subscriber 1: value = ${val}`)
);
observable$.subscribe(
  val => console.log(`subscriber 2: value = ${val}`)
);

This code will generate the following output on the console:

0.9843346569918552 
 subscriber 1: value = 0 
0.34568357780332915 
 subscriber 2: value =  0 
0.6003854545732459 
 subscriber 1: value = 1 
0.12901900745674388 
 subscriber 2: value =  1 
0.3773574643703079 
 subscriber 1: value = 2 
0.5661793730325613 
 subscriber 2: value =  2

So we get one random number (the tap of the original observable) for each execution of one of our subscribers. That's because each subscriber has their own version of the producer and its values (or the observable chain as I called before).

Multicasting our values

RxJS offers some operators that allow us to turn our regular unicast observables into multicast, which means that all subscribers will share the same instance of the producer and its values.
Two of them are share and shareReplay. There are others, but I find these to be the most useful ones for my use cases.

If we change the previous block of code and add the share operator to our observable like this:

const observable$ = interval(2000).pipe(
  take(3),
  tap(() => console.log(Math.random())),
  share()
);

observable$.subscribe(
  val => console.log(`subscriber 1: value = ${val}`)
);
observable$.subscribe(
  val => console.log(`subscriber 2: value = ${val}`)
);

It will now produce the following output in the console:

0.15433905642184453  
 subscriber 1: value = 0 
 subscriber 2: value =  0 
0.6301263674328053 
 subscriber 1: value = 1 
 subscriber 2: value =  1 
0.20325573662904373 
 subscriber 1: value = 2 
 subscriber 2: value =  2

So now we have one random number for each execution of all of our subscribers. That's because now our producer is the same for all of our subscribers.

shareReplay does the same but it also replays the last N emitted values for new subscribers. Let's take a look at another example to compare them.

ex.:

// share
const observable$ = new Subject().pipe(
    map(() => Math.random()),
    share()
  );

observable$.subscribe(
  val => console.log(`subscriber 1: value = ${val}`)
);
observable$.subscribe(
  val => console.log(`subscriber 2: value = ${val}`)
);

// lets emit one value
observable$.next();

// creating a third "late" subscriber
observable$.subscribe(
  val => console.log(`subscriber 3: value = ${val}`)
);

// emitting a new value
observable$.next();

This will produce the following output:

subscriber 1: value = 0.20616823116285787 
subscriber 2: value = 0.20616823116285787 
 
subscriber 1: value = 0.3700900273970813 
subscriber 2: value = 0.3700900273970813 
subscriber 3: value = 0.3700900273970813

So everyone is getting the same value as expected. Also, the third subscriber only received the value emitted after its creation. We can use shareReplay to cache the last emitted value (or N last values) so every new subscriber can process it.
Let's change the example above and replace the share operator with the shareReplay one.

// shareReplay
const observable$ = new Subject().pipe(
    map(() => Math.random()),
    shareReplay(1) // we can define how many values we want to cache and emit to our new subscribers, in this case we will keep only the last one.
  );

observable$.subscribe(
  val => console.log(`subscriber 1: value = ${val}`)
);
observable$.subscribe(
  val => console.log(`subscriber 2: value = ${val}`)
);

// lets emit one value
observable$.next();

// creating a third "late" subscriber
observable$.subscribe(
  val => console.log(`subscriber 3: value = ${val}`)
);

// emitting a new value
observable$.next();

Now our code will generate the following:

subscriber 1: value = 0.990542441625698 
subscriber 2: value = 0.990542441625698 
subscriber 3: value = 0.990542441625698 
 
subscriber 1: value = 0.8445875342331315 
subscriber 2: value = 0.8445875342331315 
subscriber 3: value = 0.8445875342331315

As we can see, the third observable received the first emitted value even though it was late to the party.

This is all for now, I hope this can be helpful to someone else.
Cheers and bye for now.

References:
https://rxjs.dev/api/operators/share
https://rxjs.dev/api/operators/shareReplay

TIL: Using AutoFixture with auto mocking is awesome.

Pedro Osternack Corrêa — Fri, 05 Mar 2021 00:48:37 +0000

I'm working on a .net core project and going through the tests I got my first contact with AutoFixture which is a tool that can ...create values of virtually any type without the need for you to explicitly define which values should be used. So it can help with the creation of mock data (the main use I was aware of so far) and test doubles, making life a bit easier.

Today I've found out that it has an integration with the mocking library we're using, Moq that makes it work as a DI container that provides mocks of dependencies for your classes.

ex.:

// Initializing each mocks and the SUT by hand
private ServicyMcServiceFace CreateFixtureFullManual()
{
    var dep1 = new Mock<IDependency1>();
    var dep2 = new Mock<IDependency2>();
    var dep3 = new Mock<IDependency3>();

    return new ServicyMcServiceFace(dep1.Object, dep2.Object, dep3.Object);
}

// Initializing each mocks manually and use AutoFixture for the SUT
private ServicyMcServiceFace CreateFixtureSemiAuto()
{
    var fixture = new Fixture();

    var dep1 = new Mock<IDependency1>();
    var dep2 = new Mock<IDependency2>();
    var dep3 = new Mock<IDependency3>();

    fixture.Register(dep1.Object);
    fixture.Register(dep2.Object);
    fixture.Register(dep3.Object);

    return fixture.Create<ServicyMcServiceFace>();
}

// Going full auto with AutoFixture.AutoMoq
private ServicyMcServiceFace CreateFixtureFullAuto()
{
    // We configure the Fixture to use the necessary customization
    var fixture = new Fixture().Customize(new AutoMoqCustomization());
    return fixture.Create<ServicyMcServiceFace>();
}

As we can see above the SUT initialization became way simpler since we don't need to initialize each dependency by hand.

Now, what if we want to specify a behaviour for one of our mocks? Well, we can do that by using the freeze method of our fixture.

ex.:

[Test]
public void DoTheThing_Dep1ReturnsNegativeNumber_SignalsThatNegativeWasReceived()
{
    // Initializing the fixture object with the AutoMoq Customization
    var fixture = new Fixture().Customize(new AutoMoqCustomization());

    // Freezes the instance of the IDependency1 Mock that will be used in this scope.
    // With it we can set up the Mock and it will be used on the instantiation of our SUT later on.
    fixture.Freeze<Mock<IDependency1>>().Setup(d => d.GetAnswer(), -42);

    // The created object will receive the mock as we set up previously
    var sut = fixture.Create<ServicyMcServiceFace>();
    sut.DoTheThing();

    Assert.True(sut.GotNegativeAnswer);
}

Awesome right? It makes life way simpler, mainly with you're dealing with Classes with tons of dependencies. I feel that the ability to use AutoFixture to manage all dependencies and only really get what you need when you need is a very powerful one and can make tests way simpler and a bit cleaner by removing a good amount of code from the setup step.

Hope this can be helpful to someone else.
Cheers.

Some sources:
Freezing mocks by Mark Seemann
AutoFixture as an auto-mocking container by Mark Seemann