DEV Community: Cameron Young

Intro To DI, Aggregation Association And Composition

Cameron Young — Wed, 13 Oct 2021 01:03:30 +0000

Why are we here

Sometimes while learning software concepts. I like to dig a few layers deeper to understand better. One of my older mentors used to say, “You have to bring books to the books sometimes.” While reading Dependency Injection principles, practices, and patterns, another book kept popping up into my head. The object-oriented thought process. The dependency injection book has been a great read. I even recommend it. Yet as my reading progressed. My early definition of dependency injection, "A set of software design principles and patterns that enables you to develop loosely coupled code." I asked myself. What is the smaller subset of this principle? My experience in software has been. That if it is complex. You can probably break it down into smaller components.

I will stop there and focus on how composition and inheritance kept popping up. I found many views on the subject. Even the object-oriented thought process book tells the reader, "the views it had could be contested." So using that and other sources, we learn that dependency injection relies on composition. It is a way to implement Inversion Of Control. IOC it and dependency injection are related. Dependency injection is one of many ways to implement IOC. So I will stop there and focus on how composition aids us in DI.

So what is composition? Why should we use it? I got many definitions depending on where I looked. Sticking with the book The object-Oriented Thought Process, they define composition as an object that is built from other objects.

Why use it?

First, why should we use it? We do not have many options if we want to build classes from other classes. There is inheritance and composition. Many people have issues with inheritance and are very vocal. I am not, I think it's a tool. If it can help you, use it. If it doesn't fit your needs don’t use it. Can’t speak for everyone but my anecdotal experience from college was you learned only inheritance. So armed with that knowledge you would force that into everything you did through inheritance. Even if it was not needed. This brought up another underlying concept of has-a vs is-a.

The same way in physics you have molecules, atoms, protons, neutrons, electrons, and the army of quantum particles like quarks. Is the same way many software concepts can come together and form bigger concepts. Back to Is-a and Has-a. The Is-a relationship is represented by inheritance, this is a separate concept. Inheritance is tightly coupled to polymorphism. Let's remember that inheritance allows a class to inherit the attributes and methods of another class. This allows the creation of brand new classes by abstracting out common attributes and behaviors. This is why when a class inherits from a parent class it is of the same type.

Code example of inheritance

public class Mammal
{
    public void Sleep()
    {
        Console.WriteLine("zzzz");
    }

    public void WarmBlood()
    {
        Console.WriteLine("I have warm blood");
    }

    public virtual void MakeNoise()
    {
        Console.WriteLine("kaa kaa");
    }
}

class Dog : Mammal
{
    public override void MakeNoise()
    {
        Console.WriteLine("Bark Bark");
    }
}

In the above example, the dog class has two types, of course, dog but mammal as well. The dog class has access to the sleep method and anything in the mammal class that is not private. That itself is the problem. The dog class is tightly coupled to the mammal class. Any changes there now affect the dog class. If this is planned. That is not a problem. Sometimes this can lead to changes being hard or unexpected behavior when the inheritance tree starts to grow.

Lots of people will just say never use inheritance or favor composition over inheritance. I think this article covers why that is bad advice. Inheritance and composition are important techniques. When it comes to building OO systems. Take a moment to understand the strengths and weaknesses of both and to use each at the right times. This link here is a good example of

Example of the concept "favor composition over inheritance"?

link

So ending our talk on inheritance, remember this is not a damnation of that, just a deep dive. Back to composition.

Composition

With composition, a class has a field of another class interface or class. The relationship is has-a. With composition, you design your objects around what they do. Using the mammal dog example from above it would be structured like this.

class Dog
{
 Mammal mammal;
 ...
}

Here we would use the mammal object to use the make MakeNoise method. The problem here is we can not override that method. So to use composition would not be the best idea but you see how it works. While a bad example causes the example above was showing you how you can override a method. This is in the spirit of what we are shooting for but we can do better.

class A
{

}

class B
{
    var id = new A();

    id.method();
}

Composition is a foundation of dependency injection. Let's drill into this more before we move on to D.I. In short, whenever a particular object is composed of other objects. Those objects are included as object fields. The new object is known as a compound, or aggregate, or composite object. There are a few flavors of composition having a has-a relationship. The two types of composition are aggregation and associations. Note that Composition is an area where the question of which came first. Some think that composition is a form of association, and others think association is a form of composition.

Aggregation Association, and Composition

Aggregation and composition are types of association. Based on the object-oriented thought process, "In this book, I Consider aggregation and association to be types of composition, all though there are varied opinions on this" looking at StackOverflow this is very true. This is even boiled down to just association and aggregation. The main difference being with aggregation you normally see only the whole and in associations, you normally see parts that make up the whole.

A "owns" B = Composition: B has no meaning or purpose in the system without A

A "uses" B = Aggregation : B exists independently (conceptually) from A

A Text Editor owns a Buffer (composition). A Text Editor uses a File (aggregation). When the Text Editor is closed, the Buffer is destroyed but the File itself is not destroyed.

Composition over Inheritance

Covered above many blogs and posts. Many others want you to favor composition over inheritance, due to its "is-a" VS "has-a relationship". The main issue being inheritance is overused in many situations and could lead to tight coupling. When changes in the parent class break functionality in the child classes. Then we have a design issue. What should the structure of the hierarchy look like and when new components are needed how do you integrate them into your current system.

The problem with this example is not in its ability to explain contracts but in how they could be extended. If we needed a reptile with the same properties as a mammal. We would only have a few options. Make lizard a subclass of mammal. This is bad practice lizards are not warm-blooded. We would have methods that do not fully apply to us. I have personally seen this in a few code bases. Create a reptile superclass with the same properties as a mammal, this is also bad in my eyes as now we have code duplication. Moving from an is-a to a has-a relationship we move away from this complexity, the fragile base class problem.

You can learn and use DI without knowing this in great depth. I just find it helps to know the tools you are using.

Original post here

An Example of Reflection

Cameron Young — Fri, 23 Apr 2021 03:09:31 +0000

"I understand reflection but I have never used it to solve a problem" - Me

Like most people during covid, I missed my coding groups!!! I use to belong to three or four groups. While they are still around none of my local branches decided to go virtual. So I expanded my options and dropped into any open C# groups. I enjoyed it. Excluding my main coding group I had not been around other non-work devs. We would have talks about bout complex things. One thing that kept popping up was refection. Most of the people I am around are more experienced than me. So every time it was brought up we would just gloss over reflection and we would all laugh about why it was used. While I was laughing, I would get lost in what came next. I understood what reflection was as a concept. Never seeing it in action or using it, limited that understanding. So enough back story this is the what is reflection post.

Reflection is used when we want to operate on an object during runtime. I like to think of it as creating objects backward. Reflection is a meta-programming feature that many programming languages support. You can write code that inspects other code, the same system, or even itself. It sometimes can modify the behavior of that code or methods during runtime. That is my more technical definition. I was able to come up with that after I figured out my simple example.

In reflection, we are interested in the types and members. Typically in a program, you create objects, call functions, set values for the properties of this class. When using reflection, things are different you have to construct what you are going to reflect on. We are not interested in the instance or its values, properties but we are interested in its type itself. What properties and methods it has. We can call those methods at run time.

Looking at the Microsoft doc, all I have to do is use the GetType method and bam magic!! That was not enough for me. Seriously there is another link with more information. The way it is used and when to use it. Were still things that confused me. So I made a short and useless program. To use reflection to produce an action.

var query = from m in typeof(string).GetMethods()
            where m.IsStatic == true
            orderby m.Name
            group m by m.Name into g
            orderby g.Count()
            select new { Name = g.Key,
            Overloads = g.Count()};

            foreach(var item in query)
            {
                Console.WriteLine(item);
            }

Here we drilled into the static string class to see how many overloads each method has then ordered them first by the number of overloads then alphabetically. This was a simple example of reflection. The GetMethods method shuffles its order each call. You would not want to depend on it without a constraint. Let's look at more of a breakdown. A real-world use of reflection would be a unit testing framework. We are not going to create one, but look at how it works in an isolated point. The full code is here If you want to see how to implement a full framework this blog here is for you.

Type personType = typeof(Person);

var properties = personType.GetProperties();

foreach (var item in properties)
{
    Console.WriteLine($"Property: Type: {item.PropertyType.Name}
            | Name: {item.Name}");
}

Person person = new Person();

var methods = personType.GetMethods();
foreach (var item in methods)
{
    Console.WriteLine($"Method: Type: {item.ReturnType.Name}
            | Name {item.Name}");

    if (item.Name == "Print")
    {
        item.Invoke(person, null);
    }
}
    Console.WriteLine("-------------------------------");
    AttributeTest(typeof(Person));

    Console.ReadKey();

Let's start with the main method. We use the Type class and the typeof method. This will give us the ability to create an instance of our person type. We use the GetMethods method on that instance, now we will get all of the public methods of Person.

Here we create a person class and a custom attribute. By giving it a parameter later we can use set values during our refection process. Putting the "Attribute" in the class name seems to be the standard. I am not a fan as it is a little confusing.

public class RunMethodAttribute : Attribute
{
    public int Count { get; set; }
}

This is our simple class we will use as a stand in object.

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Phone { get; set; }
    public int ZipCode { get; set; }
}

Now we are using our custom attribute, we can set values now and use them later in our reflection call. We will use ours in a loop. You can pass many things to an attribute but you are limited the doc will cover the do's and don'ts.

[RunMethod(Count = 3)]
public void Print()
{
    Console.WriteLine($"{FirstName} {LastName}");
}

[RunMethod(Count = 3)]
public void TestMethod()
{
    Console.WriteLine("Hello from TestMethod");
}

public void Move(int newZipCode)
{
    ZipCode = newZipCode;
    Console.WriteLine($"{FirstName} {LastName} has been moved to {newZipCode}");
}

[RunMethod(Count = 1)]
public void SayHi()
{
    Console.WriteLine($"Hi {FirstName}");
}

Like above we are doing something similar in our linq statement. We are using the type class to get all of the methods of our passed in value of person. Because we are using the type class we can use all the type methods. We are using GetMethods and GetCustomAttribute with our favorite method typeof. Now we are only getting the methods that are of or custom attribute type RunMethodAttribute. With the Activator class I can be lazy and just use the CreateInstance method. Now we have what I would call our shell object (that is not an official term). Using the type class we are forced to use casting while looping. We can use our attributes to power our loop logic.

static void AttributeTest(Type type)
{
    // Get the methods
    var allMethods = type.GetMethods();
    var methodsWithAttribute = allMethods.Where(m => m.GetCustomAttribute(typeof(RunMethodAttribute)) != null);

    var obj = Activator.CreateInstance(type);

    foreach (var item in methodsWithAttribute)
    {
        var attribute = (RunMethodAttribute)item.GetCustomAttribute(typeof(RunMethodAttribute));
        Console.WriteLine($"{item.Name} run for {attribute.Count} times");
        for (int i = 0; i < attribute.Count; i++)
        {
            item.Invoke(obj, null);
        }
    }
}

For me looking at how something is used in the real world is helpful for me to know other times I may need it. For the longest, I was not able to say when to correctly using refection. I still can't but I know of real-world moments like this, EF Core and the DBContext class, or loading DLLs using Assembly.LoadFile. That helps me "reflect" on the situation I am currently working on. Then know if reflection should be used.

Lets make a simple API!

Cameron Young — Mon, 12 Apr 2021 14:07:21 +0000

We are going to create a simple REST API using a compiled language. In this example we will use asp.net core to create an API Server. We will cover the post, get, put and delete actions.

There are a lot of options to create an API. Python, JavaScript, Java and many others. In this example we will drink the asp.net kool aid. This ecosystem has great project generation and in the midwest it is the dominant choice for many companies.

In this post, I'll walk through building "Store API" style functionality.

For those following along at home, all the code is in a GitHub repository. Each commit in the repo corresponds to a step in this post.

Step 1 - Generate the project

This assumes you have the .NET Core SDK or Visual Studio Community installed. If you have Visual Studio Community do the following:

Go to File > New > Project…

Select the Visual C# project category and then select ASP.NET Web Application (.NET Framework)

Name your project AspNetWebApiRest and click OK

Select the Empty project template and click OK (don’t check any boxes to add core references)

dotnet new webapi -o StoreApi
cd StoreApi
dotnet add package Microsoft.EntityFrameworkCore.InMemory
code -r ../StoreApi

This generates a simple ASP.NET API website. We are using an InMemory database for speedy development. This would not be a proper set up for a live site, it is not complicated to add one later.

Step 2 - Build out the Domain Model

In this step, we build a few simple classes.

/Models/Products.cs

public class Products
{
   public int Id { get; set; }
   public string Sku { get; set; }
   public string Name { get; set; }
   public string Description { get; set; }
   public decimal Price { get; set; }
   public bool IsAvailable { get; set; }

   public int CategoryId { get; set; }

   /// <summary>
   /// This is to stop a circular reference
   /// </summary>
   [JsonIgnore]
   public virtual Category Category { get; set; }
}

/Models/User.cs

public class User
{
    public int Id { get; set; }
    public string Email { get; set; }
    public virtual List<Order> Orders { get; set; }
}

/Models/Category.cs

public class Category
{
    public int Id { get; set; }
    public string Name { get; set; }
    public virtual List<Product> Products { get; set; }
}

/Models/Order.cs

public class Order
{
    public int Id { get; set; }
    public DateTime OrderDate { get; set; }
    public int UserId { get; set; }

    /// <summary>
    /// This is to stop a circular reference
    /// </summary>
    [JsonIgnore]
    public virtual User User { get; set; }
    public virtual List<Product> Products { get; set; }
}

Step 3 - Build out Entity Framework Core

We will install two nuget packages to get the ball rolling.

Install-Package Microsoft.EntityFrameworkCore.InMemory -Version 3.1.7

And

Install-Package Microsoft.EntityFrameworkCore -Version 3.1.7

In this section we will first create the ShopContext class. Here we will add entity framework core into the project and seed the database.

/Models/ShopContext.cs

public class ShopContext : DbContext
{
    public ShopContext(DbContextOptions<ShopContext> options) : base(options)
    { }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Category>().HasMany(c => c.Products).WithOne(a => a.Category).HasForeignKey(a => a.CategoryId);
        modelBuilder.Entity<Order>().HasMany(o => o.Products);
        modelBuilder.Entity<Order>().HasOne(o => o.User);
        modelBuilder.Entity<User>().HasMany(u => u.Orders).WithOne(o => o.User).HasForeignKey(o => o.UserId);

        // modelBuilder.Seed();
    }

        public DbSet<Product> Products { get; set; }
        public DbSet<Category> Categories { get; set; }
        public DbSet<Order> Orders { get; set; }
        public DbSet<User> Users { get; set; }
}

Let us explore what is going on in this class. We will use the documentation to configure the DbContext. After that we had to tell Entity Framework the relation between those model classes. We are using the Fluent API in Entity Framework Core for our mappings mappings. You can dive deeper into how to use them here but going into detail about that concept is outside the scope of this writing.

We will also add an extension method to seed the database with values

/Models/ModelBuilderExtensions.cs

This file is too long to give a preview for so just copy it using the link above.

With all of that the project is now set up for us to start working on some crud operations. So let's get to it.

Step 4 - Build out the GET

Here we are going to create the GetAllProducts and GetProduct(int id) methods. As the name implies the get all products will all of the products. The get product will use the product id to pull back that specific product.

public class ProductsController : ControllerBase
{
    private readonly ShopContext _context;

    public ProductsController(ShopContext context)
    {
        _context = context;

        _context.Database.EnsureCreated();
    }

    [HttpGet]
    public IActionResult GetAllProducts()
    {
        return Ok(_context.Products.ToArray());
    }

    [HttpGet("{id}")]
    public IActionResult GetProduct(int id)
    {
        var product = _context.Products.Find(id);
        return Ok(product);
    }
}

We have already created our Context class. The context object is how we interact with the runtime database. Using the Find and ToArray call from the context object are the backbone of our methods.

That’s it for the GET calls!!!

Step 5 - Build out the POST

Here we will need some extra software to implement this. I use Insomnia but there is nothing wrong with anything else. We will use the following json to test our new code.

{
    "name": "Old Skater Jeans",
    "sku": "AWMGSYYJ",
    "price": 68.00,
    "isAavailable": true,
    "categoryId": 1
}

Using the api client of your choice we will put that json in the body of your PUT call. We will add the following method to now receive PUTs.

[HttpPost]
public ActionResult<Product> PostProduct([FromBody] Product product)
{
    _context.Products.Add(product);
    _context.SaveChanges();
        return CreatedAtAction (
            "GetProduct",
            new { id = product.Id },
            product
        );
}

With this in our controller we can accept a call and we can test this and see the update in the system.
In this method we are using EF core and CreatedAtAction call. The EF is just an add for the moment and the CreatedAtAction returns a created (201) response with a location header. In another post we will add to this but for now this is a simple example.

Step 6 - Build out the PUT

In this section we will work on the update portion of the api. We will use similar json but with some changes.

{
    "name": "Super Old Skater Jeans",
    "sku": "AWMGSYYZZ",
    "price": 168.00,
    "isAavailable": true,
    "categoryId": 1
}

There are just a few updates to the name, sku and price. We will have to use the correct path to trigger a put, https://localhost:{your port number}/products/{the id of the product you want to update}. Now just so we are on the same page there should not be curly braces in your actual url. That's just for us.

We will add the new put method now.

[HttpPut("{id}")]
public IActionResult PutProduct([FromRoute] int id, [FromBody] Product product)
{
    if (id != product.Id)
        {
            return BadRequest();
        }
    _context.Entry(product).State = EntityState.Modified;

    try
        {
            _context.SaveChanges();
        }

    catch (DbUpdateConcurrencyException)
        {
            if (_context.Products.Find(id) == null)
            {
                return NotFound();
            }
                throw;
        }
            return NoContent();
}

Here we are working with many of the same objects, nothing new or fancy. We are using BadRequest, NotFound, and NoContent. Using EntityState we have a lot of options but it is too much to go over in this small section. From the documentation it is "Modified: the entity is being tracked by the context and exists in the database, and some or all of its property values have been modified". That should be enough to keep us going.

Step 7 - Build out the DELETE

Ok we are at the home stretch. The delete will act the same way as our put method. Except in our tool we will select delete instead of put to see some action.

[HttpDelete("{id}")]
public async Task<ActionResult<Product>> DeleteProduct(int id)
{
    var product = await _context.Products.FindAsync(id);
    if (product == null)
    {
        return NotFound();
    }

    _context.Products.Remove(product);
    await _context.SaveChangesAsync();
    return product;
}

This is it for our basic api!! We will add some more changes to this project in a later post. Some of the things we will cover will be adding a full database to this, paging, filtering, searching and sorting and more. Thank you for reading!!!!

And we're done. You can see all the changes in order by looking at the commits in order.

Or just see the final result at https://github.com/cmmsolutions/SimpleStoreAPI.

A Deeper Dive Into SQL

Cameron Young — Sun, 04 Apr 2021 04:23:42 +0000

To me, SQL was a strange language at first. The basics will get you far. I am the kind of person who needs to know how the insides of something works. Tends to help me utilize the tool better sometimes. For the longest, I was able to do simple selects, queries, updates, queries, and some joins. That was more than enough to get my common daily tasks done.

The longer I worked in development, the expectations of my skills increased as well. I quickly found out working with relational databases required a different thought process than my frontend work or server-side middleware work did. When I found out breakpoints did not stop the query and show all of the information at hand. I figured it was time to learn SQL. So, when in doubt, always go back to the basics. I went all the way back to my college training. I wanted to know the full SQL process.

I did not go over Relational Algebra or Relational Calculus. That seemed too technical. Learning the life cycle of a SQL query seemed like a good start.

The SQL query logical processing order

The query processing order has a unique flow as it is not top-down like a lot of other languages. The order is as follows

From (Source Data)
Where (Row filters)
Group By (Grouping)
Having (Group Filter)
Select (Return Expressions)
Order By (Presentation Order)
Offset Fetch (Paging)

This was my first step in understanding the flow of a query and how to get the correct data back. Moving away from ad hoc SQL query writing was a breath of fresh air. Now I had gotten the foundation laid out. The next thing on my list was joining.

How Joins work under the hood

Cartesian products
Every join begins with a cartesian product. A cartesian product is where each row from one set is paired with each row from the other. This will give you a set that consists of all columns from both sources.

Qualified joins
Inner and outer joins are both qualified joins. The qualification predicate is specified using the ON keyword. So, each row from the cartesian product is evaluated using the predicate. Only when the predicate evaluates to true will move on. All the other rows are eliminated from the set. With inner joins, the processing stops at this point and the rows are passed to the next clause. If the requested join type is an outer join, the qualified rows move on to the reservation stage. With outer joins, one or both source sets are designated as reserved. Reserved sets get to have all of the rows added to the join even those that did not pass the qualification step. So, an outer join reserves the set on the left side. So, the values on the left come back, and the nulls are placed on the right side. With right outer joins the same thing happens just flipped. Full outer joins simply reserve both sets. (NOTE this may be off or under-explained but it's the way I worded it for myself) A more correct way would be to say Right and Left joins are different in the data that is displayed based on the ON keyword. Left joins will use the left table and empty values from the right side show as null. Vice versa for the Right joins. What I was able to find out was using the left outer join as the example. A left outer join reserves the set on the left side. here it is set a, so all its rows that failed to qualify are reintroduced back into the join result since these rows had no match in set b there is no value to show for it and a null indicator is used for this inapplicable data.

Join Order

When joining multiple data sets, if you are exclusively working with inner joins, the order they are joined doesn't matter. This is not the case with outer joins, the order matter. To play with join the order we have the concept of chiastic order.

Looking at the Prototype

Cameron Young — Tue, 16 Mar 2021 23:51:53 +0000

Why I care about the prototype

To work with a lot of the cool flashy js frameworks, I was told to understand JavaScript first. Other than the scope of “this” one other concept would confuse me. The idea of prototypes would pop up, and people would always say “Don't worry about that. It is important but not really”. So for the longest, I just ignored the prototype. I could get what I needed and not really have to worry about it. After taking a real dive into es6 and understanding classes and inheritance.

The breakdown

I was noticing that JavaScript was playing by different rules than C# or Java. Side note: I do Java sometimes when needed but not as I used to back in college. Back in my day, Java was the golden child, and we implemented in it. The C++ religion was dying down, and this took its place. It is interesting to see the same pattern happen with python. My professor Dr. Hang Chen (a very sharp man who took little bs. Then there was me, and I had a ton to give) at the time had the view that using Java was making us softer coders and real coders used C++ or C. It is just funny to see this same idea come up in a new era with js and python versus other compiled languages. Okay back to prototypes. I was attacking this with the mindset of a Java/C# coder.

The What

Prototypical languages are just different. Now that I have a better understanding of them, I think they are kind of cool. So step one was understanding classical then prototypal inheritance. It took a second to understand that inheritance is different in this language and how simple it is. In JavaScript, all objects including functions have a prototype property. In the diagram above. The property is just a reference to another object we called proto. It would be an object that could stand on its own and could be independent if needed. So when you are calling prop 2 it is not on the object but it is actually on the object’s prototype. That prototype object can also point to another object. Each object can have its prototype. Let's use some code to see an example of the prototype chain. The prototype chain deals with where we have access to a property or method amid a sequence of objects. Those connected by this prototype property, here we are calling proto. The JavaScript engine will do the work for us by searching the prototype chain. We do not have to be explicit with our calls (Ex: we can just say object.prop2 and not object.proto.prop2) Let's see an example of this.

The Code

Here we created two objects with default values and a default function. The second object will have two properties with no function.

// Let's create a car object with some Default values
var car = {
make: 'Default',
model: 'Default',
getCarInfo: function() {
return this.make + ' ' + this.model; 
}
}

var Volvo = {
make: 'Volvo',
model: 'S80'
}

Don't do this in real life. Learn about the proto here. We read docs around here. Now Volvo inherits from car. So when calling a method that doesn't exist on Volvo it will go to Car to find it

Volvo.__proto__ = car;

// Now we can use the getCarInfo()
console.log(Volvo.getCarInfo());

We get the value of "Volvo" because of the prototype chain. It first looks on the Volvo object for that property, finds it then stops. JavaScript engine starts at the top of the chain, works its way down till it finds the needed value.

console.log(Volvo.make);

This will return "Honda Default" as the object has a value for make but not for model. So the prototype is car and finds the model value of Default

var Honda = {
    make: 'Honda'   
}

Honda.__proto__ = car;


console.log(Honda.getCarInfo());

Here we will crate a new function on the car object to hammer home the idea.

car.getCarFullInfo = function() {
    return this.model + ', ' + this.make;   
}

console.log(Volvo.getCarFullInfo());
console.log(Honda.getCarFullInfo());

The value you would get here would be "S80, Volvo" and "Default, Honda" because of how prototypes work. Get the full code here.

The original post can be found Here.

The T In TDD

Cameron Young — Fri, 12 Mar 2021 03:13:16 +0000

By this point. If you have read some of my older blog postings. You know I am a part of a programming group that is big on TDD and the DDD paradigm. My mind is all over the place and I learn 5 things at one time. During this storm of random learning. I picked up TDD while reading "Working Effectively With Legacy Code" by Michael C. Feathers.
The main focus is clearly stated in the title "Test" Driven Development.

If you are going to do TDD you will need to know how to test software. I did not learn about testing software in college. The many jobs I have worked at. Only a few of them had tests at all. Only when I became an automation developer was I forced into the world of testing. Even then I was still able to ignore many of the great benefits it offers.

Here we are going to go over a unit testing framework. There are a lot of choices like XUnit (my personal favorite), NUnit, pytest for python (My second favorite), and Jest for javascript. In our example, we will cover NUnit. While XUnit is my favorite I need to use NUnit for work so here we go!

This is more of a "how to structure" your tests. We will not go over "how" to test. Just like everything else in software, there are layers to testing. Picking a testing framework, assertion framework, and maybe a mocking framework. There could be more depending on your needs.

Personally, starting something is hard. I always get hung up on best practices and structure. This post will not jump into best practices as that is a post all of its own but just lightly touch the options you have in a testing framework. This should get you started on your TDD journey.

Many frameworks follow an attribute pattern. They use attributes to dictate functionality. I will cover the NUnit style. XUnit shares a history with NUnit and both are extremely popular. There are reasons to pick one over the other but that again is a post by itself. Some frameworks won't follow the same attribute style per-se such as PyTest for python. The spirit of it is still there as Pytest will do something like @pytest.fixture above a method.

There are many attributes available in a test framework. Some of the most common are fixtures, test, set up, tear down, ignore, and category. There are more options but we will narrow our focus. There is a long list and you can find all of the NUnit attributes here.

Let us start with fixtures. They are to ensure that there is a known environment so test results are repeatable. In plain English, it takes a lot of work to set up a test then reset everything after the test has run. We plan to execute this test many times. So we want an easy way of making sure this process is repeatable. Below is a simple example

    [TestFixture]
    public class Tests
    {
        // ...
    }

There are a few ways you can use to structure your fixtures depending on your needs. One of those patterns is the abstract test pattern. This is a pattern for when you want to test several implementations. You could write a test for each implementation or you could create an abstract class containing all of the tests. Then using a factory pattern you implement each concrete test.

    namespace UnitTestProject1
    {
        public class TestArrayList : BaseTestStringList
        {
            protected override IList CreateList()
            {
                return new ArrayList();
            }
        }

        public class TestStringCollection : BaseTestStringList
        {
            protected override IList CreateList()
            {
                return new StringCollection();
            }
        }

        [TestFixture]
        public abstract class BaseTestStringList
        {
            private IList list;

            [SetUp]
            public void SetUp()
            {
                this.list = CreateList();
            }

            protected abstract IList CreateList();

            [Test]
            public void TestAdd()
            {
                object item = Guid.NewGuid().ToString();
                int beforeCount = this.list.Count;
                this.list.Add(item);
                Assert.AreEqual(beforeCount + 1, this.list.Count);
            }

            [Test]
            public void TestContains()
            {
                object item = Guid.NewGuid().ToString();
                int beforeCount = this.list.Count;
                this.list.Add(item);
                Assert.IsTrue(this.list.Contains(item));
            }

            [Test]
            public void TestClear()
            {
                object item = Guid.NewGuid().ToString();
                this.list.Add(item);
                this.list.Clear();
                Assert.AreEqual(0, this.list.Count);
                Assert.IsFalse(this.list.Contains(item));
            }
        }
    }

Source

This is just one way of using inheritance, generics, or parameterization. You can create a pattern that works for you. Depending on the language you choose to use. There may be pattern limitations or you will have to structure them differently. When moving from a c# automation project to a python project. I had to rethink a lot of what I did. Eventually we threw away our page object pattern. For a more dynamic data-driven approach using JSON files.

The test attribute just marks a test case. More specifically this attribute lets the test runner know this method should be run.

 [TestFixture]
  public class SuccessTests
  {
    // A simple test
    [Test]
    public void Add()
    { /* ... */ }
    ....
  }

So there are two types of teardowns. We have the OneTimeTearDown and the TearDown. The OneTimeTearDown attribute is set on methods that run once after executing all the tests in a fixture. The TearDown, unlike the OneTimeTearDown, this attribute will trigger after the test method. OneTimeSetup is best used for costly steps like creating a database. It is more on the integration test side of things. Like everything in software, the tool is at your disposal.

namespace NUnit.Tests
{

  [TestFixture]
  public class SuccessTests
  {
    [OneTimeSetUp]
    public void Init()
    { /* ... */ }

    [OneTimeTearDown]
    public void Cleanup()
    { /* ... */ }

    [Test]
    public void Add()
    { /* ... */ }
  }
}

The OneTimeSetup and SetUp attributes work the same way in reverse.

The Ignore attribute will skip any test it is applied to.

This is a good starting point for working with a test framework. There is more to testing than this. Remember this is more of a "how to structure" your tests. So we did not go over how to test at all. Eventually, you would want to assert that the data you get is the data you expect.

When I was introduced to testing I was not aware of any framework options patterns or ways to structure my tests. Or even how to test.
In the dot net space, you can unit test razor pages, controllers, and middleware. Testing things like this can help you maintain the integrity of your project as it grows or if you need to do a refactor down the line.

Say you are moving from an ORM to a more traditional database setup. For whatever reason. Having tests fail while you are working on the migration. Everything is fresh and you are in the same headspace. Is a lot better than the same bug popping up 6 months later. By then you are on to something else.

The original post can be found Here.