DEV Community: Shuto Osawa

Return Early To Reduce Deeply Nested If-Statements

Shuto Osawa — Mon, 26 Sep 2022 11:47:39 +0000

Introduction

It is easy to introduce deep nesting in the code. There are several techniques to reduce the deep nesting. One of these techniques is called "Return Early". By reducing the deep nesting, it allows us to follow the logic easily. We can also spot potential bugs without spending too much time. I revisited Return Early technique recently and it will be the main content of this post.

Deep nested validation

Let's consider a method that returns a particular string depending on the input. The ideal input string would be "cat", and there are five things we need to check.

null or empty
shorter than 7 letters
contains "bad words"
contains any digits
is "cat"

We can implement the validation above one by one.

nested if statements

public string CheckInputString(string inputString)
{

    string[] badWords = { "dog", "dogs" };
    if (!String.IsNullOrEmpty(inputString))
    {
        if (inputString.Length < 7)
        {
            if (!badWords.Contains(inputString))
            {
                if (!inputString.Any(char.IsDigit))
                {
                    if (inputString == "cat")
                    {
                        return "Meow";
                    }

                    return inputString;
                }

                return "the string contains numbers";
            }

            return "please dont use the bad words";
        }

        return "too long";
    }

    return "null or empty";
}

not nested if statements

We can remove all the nested if statements above by focusing on the best case senario. In this case, having the input string being "cat" would be the best case. The rest of the cases are considered "wrong". As soon as we encounter the "wrong" result, we return a value and exit the method.
As you see below, we can resolve the deep nesting by utilizing the return early technique.

public string CheckInputStringFixed(string inputString)
{

    string[] badWords = { "dog", "dogs" };

    if (String.IsNullOrEmpty(inputString))
    {
        return "null or empty";
    }

    if (inputString.Length >= 7)
    {
        return "too long";
    }

    if (badWords.Contains(inputString))
    {
        return "please dont use the bad words";
    }

    if (inputString.Any(char.IsDigit))
    {
        return "the string contains numbers";
    }

    if (inputString != "cat")
    {
        return inputString; 
    }

    return "Meow";
}

This should look a lot clearer than the previous example.

Conclusion

I revisited return early technique where we get out of the method as soon as we encounter unwanted situation by returning a value right away. This technique can be applied in many situations and it greatly increased the visibility of the code.

Learning Dependency Injection (IoC) Container in C#

Shuto Osawa — Thu, 15 Sep 2022 12:09:55 +0000

Introduction

I used to see the word "DI Container" everywhere back when I was a beginner in C#. I am finally getting used to using dependency injection and it is a good to time to revisit DI Containers.

Dependency Injection

Dependency injection is a very important technique to achive loose-coupling in a software.
Instead of writing something below, we could remove tight coupling between classes.

public class Cat
{
    public void CheckFood()
    {
        Food catfood = new Food("cat food");
        Console.WriteLine("I am eating " + catfood.Name );
    }
}

public class Food
{
    public string Name {get;set;}

    public Food(string foodName)
    {
        this.Name = foodName;
    }
}

In this case, the class Cat depends on Food.
We make the dependency better by injecting dependency from constructor.

public class Cat
{
    private Food food;
    public Cat(Food food)
    {
        this.food = food;
    }
    public void CheckFood()
    {
        Console.WriteLine("I am eating " + food.Name );
    }
}

public class Food
{
    public string Name {get;set;}

    public Food(string foodName)
    {
        this.Name = foodName;
    }
}

The difference is that the food instance is not instantiated in the cat class, the food instance is injected through constructor.

Dependency Injection Container

We can simply keep using this dependency injection technique, however the instantiation of a class can be cumbersome. DI Container frameworks can help us with this work.

Simple implementation of interface through DI Container

Let's consider an IAnimal interface with dog and cat classes. They make different noises and we want to listen to them.

No DI Container

    public interface IAnimal
    {
        void noise();
    }

    public class Cat : IAnimal
    {
        public void noise()
        {
            Console.WriteLine("meow");
        }
    }

    public class Dog : IAnimal
    {
        public void noise()
        {
            Console.WriteLine("bark!");
        }
    }

It is very easy to instantiate them even without the container.

IAnimal cat = new Cat();
IAnimal dog = new Dog();
cat.noise();
dog.noise();

That's it!

With DI Container

container.RegisterType<IAnimal, Cat>();
container.RegisterType<IAnimal, Dog>();

IAnimal cat = container.Resolve<Cat>();
cat.noise();
IAnimal dog = container.Resolve<Dog>();
dog.noise();

We can register the relationship between IAnimal and Cat. We can do the same for the dog class as well.
Since the relationship is registered to the container, we can create the object by calling Resolve method.

Somewhat complicated case

The example above is too easy and it does not really show the usefulness of the DI container.

Without DI Container

What if we have a object that depends on 9 containers and we want to use DI to implement it.

The constructor would look like this.

ParentObj parentObj = new ParentObj(new Obj1(new Obj4(), new Obj5(new Obj8())), new Obj2(new Obj6(new Obj8())), new Obj3(new Obj7(new Obj9())));

This is fine if we only need to use this object once, but we may need to use something like this over and over.

With DI Container

With a DI container, we can make the instantiation part simple after properly wire them up.
The wiring process can be tedious, but we only need to do it once.

container.RegisterType<Obj8>();
//setup obj1
container.RegisterType<Obj4>();
container.RegisterType<Obj5>(new InjectionConstructor(container.Resolve<Obj8>()));
container.RegisterType<Obj1>(new InjectionConstructor(container.Resolve<Obj4>(), container.Resolve<Obj5>()));

//setup obj2
container.RegisterType<Obj6>(new InjectionConstructor(container.Resolve<Obj8>()));
container.RegisterType<Obj2>(new InjectionConstructor(container.Resolve<Obj6>()));

//setup obj3
container.RegisterType<Obj9>();
container.RegisterType<Obj7>(new InjectionConstructor(container.Resolve<Obj9>()));
container.RegisterType<Obj3>(new InjectionConstructor(container.Resolve<Obj7>()));

container.RegisterType<ParentObj>(new InjectionConstructor(container.Resolve<Obj1>(), container.Resolve<Obj2>(), container.Resolve<Obj3>()));

Now we can generate the parent object.

ParentObj containerParentObj = container.Resolve<ParentObj>();

I have used simple objects in this example, but in reality each object can be complicated and this could greatly reduce the pain of low readablity.

Where should I put the container

I had some questions about placing the container. I understood that the container can perform a lot of work for us, once all the classes are wired properly. Once we have the container, do we need to pass the containers around??
When we pass the container around classes then it becomes the service locater pattern and it is often seen as an anti-pattern.
The container should never leave the composition root and all the instances should come from the composition root.

Conclusion

I have looked into the basic usage of DI Containers in C#. I did not go over the details of how we can use the DI Container, such as checking instance life cycles. However, it is a good starting point to understand the DI container itself.

Learning GitHub Runner Self-Hosting with Windows Desktop Application

Shuto Osawa — Mon, 29 Aug 2022 14:21:00 +0000

In the previous post, I talked about running .NET application using CLI. Now, we can use GitHub actions and run unittest for the desktop application.

GitHub provides action runner, so we can use their runners without self-hosting a runner. At my work, we were not able to use GitHub provided runners. Therefore, we had to self-host a runner to introduce CI.

GitHub provides a very gentle introduction to setup a runner. All we need to do is copy and paste their instruction.

GitHub Settings

We can construct a runner by simply visiting GitHub settings.

Since I am working on Windows Desktop App, I chose Windows Runner Image.

We need to download the runner package and then, configure a runner on your computer.

After proper setup of the the runner, we should be able to use the runner we just configured. In my case, I see "TestRunner".

Configure yml file

We can use the runner in the workflow. We setup the workflow for .NET 6 Windows Forms application.

name: .NET Framework Desktop
on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

jobs:

  build:
    #The runs-on below needs to match the tags of the runner.  
    runs-on: [self-hosted, Windows,x64]

    steps:
    - uses: actions/checkout@v1
      name: Checkout Code

    - name: Add msbuild to PATH
      uses: microsoft/setup-msbuild@v1.1

    # Execute all unit tests in the solution
    - name: Execute unit tests
      run: dotnet test

The workflow syntax can be found in their official documentation, so I will not go into details of it.

In the last line of the yml file, this is what I wanted to achieve in this post.
I want to run the test everytime I push my code to this repository.

Using dotnet CLI for Winforms with .NET 6 and .NET Framework 4.8

Shuto Osawa — Sun, 31 Jul 2022 06:18:00 +0000

Introduction

I have been interested in running some of my winforms based projects on CI services. However, preparing workflows for winforms application was cumbersome. It was primarily due to the fact that my projects uses .NET Framework 4.8. In order to be able to use CI service, we need to be able to build the solution or run test projects on the service. For example, Github Actions provide some templates for .NET (also assuming they work for .NET Core). The template does not work with .NET Framework based solutions. I was not able to find a good and easy solution for this. When I was analyzing the template on Github Action, it occured to me that I need to be able to use dotnet CLI first. The details of dotnet CLI can be found here.

Using dotnet CLI for .NET Framework

Though dotnet CLI allows us to create a winform project and run it through command line, it is not as easy to run already created project with .net framework.
When we perform "dotnet run" in command line, we may see this kind of error.

Moving to .NET 6

The problem above can be resolved using .NET 6 instead of .NET Framework. Fortunately, .NET 6 supports winforms, so we can use it instead of .NET Framework. In this setting, dotnet run works and we can run the project.

This warning can be removed by changing to in the .proj file.

After changing the line, the warning disappeared.

Using dotnet CLI with .NET Framework 4.8

Despite the fact we were not able to use dotnet run in a simple fasion, we can use the CLI if we modify the .csproj file.
If we have the same structure in the .proj file, we should be able to use the CLI since it supports both .NET 6 and .NET Framework.
I have tried the following by copying the structure of the .NET 6 .csproj file into .NET Framework .csproj file.

.NET 6

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net6.0-windows</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>
  </PropertyGroup>
</Project>

.Net Framework 4.8

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net48</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>
    <StartupObject>winformsCLI.Program</StartupObject>
  </PropertyGroup>
</Project>

After replacing the file, now we can use the CLI. The program runs without any problems, however, I am not entirely sure if this substitution is problematic or not.

Adding unittest in the solution

We can now run the project using the CLI. It would be valuable if we are able to run the unittest as well. There is another obstacle when it comes to switching from .NET framework to .NET 6.
The winforms program shows the text this is tofu when the button is clicked. Tofu, being my cat.

We would like to write a test to check if the text is correct or not. The code for the winforms is the following.

namespace WinformsCI
{
    public partial class Form1 : Form
    {
        private StringGen gen = new StringGen();
        public Form1()
        {
            InitializeComponent();
        }

        private void button1_Click(object sender, EventArgs e)
        {
            textBox1.Text = gen.GetString();
        }

    }

    public class StringGen
    {
        public string GetString()
        {
            return "this is tofu";
        }
    }
}

And here is the prepared test for it.

  public class Tests
    {
        private StringGen gen;
        [SetUp]
        public void Setup()
        {
            gen = new StringGen();
        }

        [Test]
        public void Test1()
        {
            string result = gen.GetString();
            Assert.AreEqual("this is tofu", result);
        }
    }

Unfortunately, we cannot run this test because the winforms project relies on .NET 6-windows.

The test project's target framework is .NET 6 and the OS is not specified. Therefore, we need to add specified the OS in the property.

After doing it, we can run the test.

We should be able to use the CI services now and I would like to run the test using Github action next.

How I Developed a Habit of Writing Unittests

Shuto Osawa — Wed, 20 Jul 2022 12:04:15 +0000

Introduction

Since I started my career in software engineering, there are a myriad of skills I had to learn aside from 'writing code'.
I am primarily using C# at my work, and object-oriented coding was a foreign language for me, being that I have only done numerical calculations using other programming languages. At the time, there was no need for me to really think about classes and their relationship to other classes.

Difficulty at work

After nailing down some basic coding, it occured to me that I did not want to maintain what I have been writing due to the fact that the software was too messy and loose coupling was not achieved.
My company does not enforce code review or writing unittests, therefore the quality of the code is up to me.
This motivated me to get serious about researching on software development and increasing its quality.
The code I have been writing was in need of some serious refactoring, and I decided to start with writing unittests.

Meeting unittesting

Because my company does not enforce writing automated tests, the importance of it was lost on me. However, once I developed the habit of writing test code I could see the power of writing them, particularly when it comes to refactoring.
In this post, I will talk about how was able to grow accustomed to writing unittests. I was struggling greatly with actually applying them because I did not know that my code was not exactly testable.
There is plenty of information about unittesting online and how to do it right. So, I will simply talk about my personal experience.

One of the most basic examples provided online

The easiest unittest might be a method performing summation.

public class Arithmetic
{
    public int Summation(int a,int b)
    {
        return a + b;
    }    
}

We can write a unittest for this code in NUnit in the following way.

public class Tests
{
    private Arithmetic arithmetic;
    [SetUp]
    public void Setup()
    {
        arithmetic = new Arithmetic();
    }

    [Test]
    public void SummationTest()
    {
        //Arrange
        int a = 1;
        int b = 1;
        //Act
        int result = arithmetic.Summation(a,b);
        //Assert
        Assert.AreEqual(2,result);
    }
}

The code above passed the test. We can obviously write tests if the production code is simple enough like the summation example above. We have checked that 1+1 returns 2.

Different example

Consider an example of getting relative distance between a house and a cat. First, prepare a cat class and he has a house. The house instance will be generated within the cat class, so I will call it a coupled cat class.

public class House
{   
    public int Location { get; set; }
}

public class CoupledCat
{
    private House house;
    public int Location { get; set; }

    public CoupledCat()
    {
        house = new House();
        house.Location = 1;
    }

    public int RelativeDistance()
    {
        return Math.Abs(house.Location - this.Location);
    }
}

We can run the code.

static void Main(string[] args)
    {

        //Prepare a cat with his house information
        CoupledCat cat = new CoupledCat();
        cat.Location = 3;

        //get distance
        int rel = cat.RelativeDistance();
        Console.WriteLine("you need to walk "+rel+" meter(s)");        
    }

Test for coupled cat class

We can write a test for the CoupledCat class.

public class CoupledCatTest
{
    private CoupledCat cat;
    [SetUp]
    public void Setup()
    {
        cat = new CoupledCat();
    }

    [Test]
    public void DistanceTest()
    {
        //Arrange
        cat.Location = 3;
        //Act
        int result = cat.RelativeDistance();
        //Assert
        Assert.AreEqual(2,result);
    }
}

We can write a test for this class, however it is inconvenient since the house location is fixed in the coupled cat class and we would like to move the house location.

Dependency injection

I would like to have some freedom in terms of house location. In order to resolve this dependency, we can introduce dependency injection. There are three ways to perform it, 1.Property Injection, 2.Constructor Injection, and 3.Method Injection.

1.Property Injection

The cat class has a House property. This injection is probably not so great since the code would not run if we forget to inject the house instance to the cat class.

public class Cat
{
    public House House { get; set; }
    public int Location { get; set; }
    public int RelativeDistance()
    {
        return Math.Abs(House.Location - this.Location);
    }
}

public class House
{   
    public int Location { get; set; }
}

Let's actually run the code. Before we run the code, the house instance needs to be injected to the cat's house property.

class Program
{
    static void Main(string[] args)
    {
        //Prepare a house
        House house = new House();
        house.Location = 1;

        //Prepare a cat with his house information
        Cat cat = new Cat();
        cat.House = house;
        cat.Location = 3;

        //get distance
        int rel = cat.RelativeDistance();
        Console.WriteLine("you need to walk "+rel+" meter(s)");
    }
}

2.Constructor Injection

We can change the injection location from property to the constructor. The house instance needs to be prepared before creating the cat clas.

public class Cat
{
    private House house;
    public int Location { get; set; }

    public Cat(House house)
    {
        this.house = house;
    }
    public int RelativeDistance()
    {
        return Math.Abs(house.Location - this.Location);
    }
}

3.Method Injection

Since we need the house class only in the RelativeDistance method, so we can inject the instance in the method.

public class Cat
{
    public int Location { get; set; }

    public int RelativeDistance(House house)
    {
        return Math.Abs(house.Location - this.Location);
    }
}

Writing a test for this house-cat example

I will write the test for property injection based cat class.

public class CatHouseTest
{
    private House house;
    private Cat cat;
    [SetUp]
    public void Setup()
    {
        house = new House();
        cat = new Cat();
        cat.House = house;
    }

    [Test]
    public void DistanceTest()
    {
        //Arrange
        house.Location = 1;
        cat.Location = 3;
        //Act
        int result = cat.RelativeDistance();
        //Assert
        Assert.AreEqual(2,result);        
    }  
}

Adding flexibility to the cat class

Though we introduced dependency injection, they are still not so flexible because the cat only knows the distance between his current location and his house. They would love to wander around the city and eat some fish. Let him have some fish!

Introducing an interface

Instead of a house we can implement a building having location information. By introducing an interface, we can look at all the classes with Location property in the same way.

public interface IBuilding
{
    int Location { get; set; }
}

The house class can implement IBuilding since the house has the location property.

public class House:IBuilding
{
    public int Location { get; set; }
}

Let's go back to the cat class. We can replace the House property in the cat class to the building interface.

public class Cat
{
    public IBuilding Building { get; set; }
    public int Location { get; set; }
    public int RelativeDistance()
    {
        return Math.Abs(Building.Location - this.Location);
    }
}

We can run the code and there is no big difference between the previous code and the new code other than replacing cat.House.

class Program
{
    static void Main(string[] args)
    {
        //Prepare a house
        House house = new House();
        house.Location = 1;

        //Prepare a cat with his house information
        Cat cat = new Cat();
        cat.Building = house;
        cat.Location = 3;

        //get distance
        int rel = cat.RelativeDistance();
        Console.WriteLine("you need to walk "+rel+" meter(s)");
    }
}

The great thing about interface is that we can introduce anything that implements the interface. Let him finally introduce a fish market.

public class FishMarket:IBuilding
{
    public int Location { get; set; }
}

class Program
{
    static void Main(string[] args)
    {
        //Prepare a house
        House house = new House();
        house.Location = 1;

        //Prepare a fishmarket
        FishMarket fishMarket = new FishMarket();
        fishMarket.Location = 5;

        //Prepare a cat with his house information
        Cat cat = new Cat();
        cat.Location = 2;
        cat.Building = house;

        //get distance
        int relToHouse = cat.RelativeDistance();
        Console.WriteLine("you need to walk "+relToHouse+" meter(s)");

        //Set fishmarket
        cat.Building = fishMarket;

        //get distance
        int relToFishMarket = cat.RelativeDistance();
        Console.WriteLine("you need to walk "+relToFishMarket+" meter(s)");
    }
}

Writing several tests

At this point, we could add some more tests and we can use TestCase attribute to perform several cases in a single method.
Let's write tests for both Cat to House distance and Cat to Fishmarket distance.
In the cat to fishmarket example, three test cases are provided. It is important to consider edge cases if necessary.

public class CatHouseTest
{
    private House house;
    private FishMarket fishMarket;
    private Cat cat;
    [SetUp]
    public void Setup()
    {
        house = new House();
        fishMarket = new FishMarket();
        cat = new Cat();       
    }

    [Test]
    public void DistanceToHouseTest()
    {
        //Arrange
        house.Location = 1;
        cat.Building = house;
        cat.Location = 3;
        //Act
        int result = cat.RelativeDistance();
        //Assert
        Assert.AreEqual(2,result);
    }

    [TestCase(0,1,1)]
    [TestCase(8,2,10)]
    [TestCase(4,-1,3)]
    public void DistanceToFishMarketTest(int expected,int catLocation,int fishMarketLocation)
    {
        //Arrange
        fishMarket.Location = fishMarketLocation;
        cat.Location = catLocation;
        cat.Building = fishMarket;
        //Act
        int result = cat.RelativeDistance();
        //Assert
        Assert.AreEqual(expected,result);
    }
}

The result is all green, so we are very happy about the result!

Using external resource

If we need to use some data outside of the current project, our test would fail and we need to modify the test.
We can prepare the text file in the C drive and we would like to read some data from the file. The file only has a single number in the text file in this example.

public class Cat
{
    public IBuilding Building { get; set; }
    public int Distance { get; set; }

    public int LoadLocationFromText()
    {
        string text = System.IO.File.ReadAllText(path+location.txt);
        return Convert.ToInt32(text);
    }
    public int RelativeDistance()
    {
        int location = LoadLocationFromText();
        return Math.Abs(Building.Location - location);
    }

}

The test passes only when the text file exists in the computer. This means that we cannot run the test if we use someone else's computer.

Introduce a testclass

we are interested in testing the RelativeDistance method and LoadLocationFromText method depends on the text file in my computer. It means that if the test is performed on someone else's computer, the test would not work unless the text file and its path are provided. It is better if we can run the test without preparing external resource.
If we are allowed to make some modification to the class methods, we can rewrite the LoadLocationFromText method using virtual keyword. If a method is virtual then we can override the method in the test. This allows us to safely ignore the external dependency part.

Let's create another class that inherits the cat class. The LoadLocationFromText has override keyword, so we can return arbitrary number instead of reading the text file.

public class CatTest : Cat
{
    private int input;
    public CatTest(int input)
    {
        this.input = input;
    }
    public override int LoadLocationFromText()
    {
        return this.input;
    }
}

public class CatHouseTest
{
    private House house;
    private FishMarket fishMarket;
    private CatTest cat;
    [SetUp]
    public void Setup()
    {
        house = new House();
        fishMarket = new FishMarket();
    }

    [Test]
    public void DistanceToHouseTest()
    {
        //Arrange
        cat = new CatTest(3);
        house.Location = 1;
        cat.Building = house;
        //Act
        int result = cat.RelativeDistance();
        //Assert
        Assert.AreEqual(2,result);
    }

    [TestCase(0,1,1)]
    [TestCase(8,2,10)]
    [TestCase(4,-1,3)]
    public void DistanceToFishMarketTest(int expected,int catLocation,int fishMarketLocation)
    {
        //Arrange
        cat = new CatTest(catLocation);
        fishMarket.Location = fishMarketLocation;
        cat.Building = fishMarket;
        //Act
        int result = cat.RelativeDistance();
        //Assert
        Assert.AreEqual(expected,result);
    }
}

Now it passes all the tests.

Conclusion

The main goal for me was developing the habit of unittesting.
However, the biggest hurdle was understanding how to write a test. I started writing tests and performed refactoring in the following manner.

Find the smallest class in the project. It is important to find a class with least amount of dependencies.
Write one easy test for the class.
If there is a huge class, break it down in smaller pieces of classes.
Write tests for those small classes.
Find a class with external dependency such as loading files, database connection and so on.
If they can be modified then make the method virtual and override the method by creating a class for test purpose.
Since the project started to have some tests, it should be easier to modify code without worrying too much about producing bugs.
Introduce interfaces here and there and also apply design patterns if there is a suitable one. At this point the code should look way better than before and I am not afraid of writing tests for my code. The next step for me would be properly preparing a mock in my test.