DEV Community: Mohamed Halawa

The Essential Unit Testing Techniques, Part 1

Mohamed Halawa — Thu, 29 Jul 2021 19:20:44 +0000

Unit testing plays a vital role in the software development process, but how do we actually test our code?

In the following article I'll try to summarize and mention various techniques followed by .NET Developer using the NUnit library.

Testing strings

Testing against specific strings is not a robust way of testing strings, For example

Assert.That(result, Is.EqualTo("<strong>abc</strong>"));

👍 As a rule of thumb, testing strings is recommended to be more general than if it was too specific it would fail with every tiny change!

👍 Strings are all about format! so any method that can test the format for you is a viable testing method!

Using string interpolation $"{}" or string.Format()
Using Does.StartWith, Does.EndWith, Does.Contain methods provided by NUnit
Using Regex (more advanced)

1. Using `$"{}"` format or `string.Format`

You can easily check the targeted format using string.format or $"{}" along with Assert.That(result,Is.EqualTo()), for example

Assert.That(result, Is.EqualTo($"<strong>{str}</strong>"));

2. Using `Does.StartWith`, `Does.EndWith`, `Does.Contain` Methods

You can also use the fellow methods to check if a string is enclosed between specific words or tags!

Assert.That(result, Does.StartWith("<strong>"));
Assert.That(result, Does.EndWith("</strong>"));
Assert.That(result, Does.Contain($"{str}"));

3. Using Regex

Regex is the god-level matching mechanism for strings! and fortunately, you can use it with NUnit to test your strings

Assert.That(result, Does.Match("<pattern>"))

Testing arrays and collections

Testing arrays or collections is a little bit tricky since there are many factors you can test

1. Testing if an Array has any elements

Assert.That(result,Is.Not.Empty)

🔘 Yet, it's a general test case!

❓How can you make sure if it has a certain count of elements?

2. Testing the count of a collection

 Assert.That(result.Count(),Is.EqualtTo(<num>))

🔘 It's also a general test case!

❓How can you make sure if it has a certain element?!

3. Testing if a collection contains X

Assert.That(result, Does.Contain(1));
Assert.That(result, Does.Contain(3));
Assert.That(result, Does.Contain(5));

🤕 It brings more headache due to the repetitive work!

⚡ Fortunately, there is another way to do just the same!

Assert.That(result, Is.EquivalentTo(new [] {1,2,3})

⁉️ What about the order of it's elements!

4. Testing the order of a collection

Assert.That(result,Is.Ordered);

⁉️ And What about the uniqueness of its elements!

5. Testing the uniqueness of a collection's elements!

Assert.That(result,Is.Unique);

Testing Methods

Like arrays, there are also many factors that you consider when testing a method or a function!

return type
return value
void methods
exceptions are thrown by methods
events being raised by a method
private methods

Testing return type

NUnit provides two different ways to test the return type of a method or a function.

Is.TypeOf<>()
Is.InstanceOf<>()

`Is.TypeOf<>()`

Checks if an instance (object or value) is of a specific type and just that type. for example:

Assert.That(result,Is.TypeOf<NotFound>());

`Is.InstanceOf<>()`

Checks if an instance (object or value) is of a specific type or one of its derivatives. for example:

Assert.That(result,Is.InstanceOf<NotFound>());

🗒️ It also provides the non-generic version of both methods, that can be used along with typeof

Testing void methods (commands)

Void methods or commands are trickier to test than anything else because they

change a state of an object either in memory, database
persist a state, they may store an object in a database or call a web service or a message queue.

Unfortunately, the only way to accomplish such a task is to preserve the state of the object being affected by that method. For example

public class ErrorLogger
{
    public string LastError { get; set; }

    public event EventHandler<Guid> ErrorLogged; 

    public void Log(string error)
    {
        if (String.IsNullOrWhiteSpace(error))
            throw new ArgumentNullException();

        LastError = error; 

        // Write the log to a storage
        // ...

        ErrorLogged?.Invoke(this, Guid.NewGuid());
    }
}

[Test]
[TestCase("Something went wrong")]
public void Log_WhenStringIsNotNullOrWhiteSpace_ThrowAnException(string message)
{
    _logger.Log(message);
    Assert.That(_logger.LastError,Is.EqualTo(message));
}

Testing methods that throw an exception

NUnit provides a way to test if a method throws a specific exception and no matter it's a built-in exception or custom exception you can always test it!

But... you cannot just call your method in a normal way and expecting the Assert to detect that exception rather you've to call it as a delegate within the Assert.That method.

So, Instead of

[Test]
[TestCase("")]
[TestCase(" ")]
[TestCase(null)]
public void Log_InvalidErrorMessage_ThrowArgumentNullException(string message)
{
    _logger.Log(message); // Execution will be stopped as a result for the exception and the test will fail!
    Assert.That(_logger.LastError,Throws.ArgumentNullException);
}

Do the following

[Test]
[TestCase("")]
[TestCase(" ")]
[TestCase(null)]
public void Log_InvalidErrorMessage_ThrowArgumentNullException(string message)
{
    Assert.That(() =>
    {
        _logger.Log(message);
    },Throws.ArgumentNullException);
}

If you notice, I've used the Throws.ArgumentNullException property to assert the result and that is a built-in exception.

❓What about the Custom Exceptions?

💬 Well, you can use the Throws.Exception.TypeOf<>() method just for that!

Testing methods that raise an event

Testing events is nothing more than testing if it was raised for a specific scenario or not, so what we gonna really need is a simple indicator to answer our question. For Example

public class ErrorLogger
{
    public string LastError { get; set; }

    public event EventHandler<Guid> ErrorLogged; 

    public void Log(string error)
    {
        if (String.IsNullOrWhiteSpace(error))
            throw new ArgumentNullException();

        LastError = error; 

        // Write the log to a storage
        // ...

        ErrorLogged?.Invoke(this, Guid.NewGuid());
    }
}

Here, our event will send an argument which is Guid.NewGuid() which we can assume to be the indicator that will tell us if it was raised or not.

[Test]
[TestCase("Something went wrong")]
public void Log_ValidError_RaiseErrorLoggedEvent(string messge)
{
    // Arrange
    var id = Guid.Empty;

        // Subscribe to the event
    _logger.ErrorLogged += (sender, arg) => { id = arg; };

    // Act
    _logger.Log(messge);

    // Assert
    Assert.That(id, Is.Not.EqualTo(Guid.Empty));
}

So, to test the event, we are going to subscribe to it first
Assign the passed Guid to a local variable, that was previously initialized with a default value.
Finally, we can assert that the Id is not the same as its default value! which means that event has already been raised and mutated the local variable.

Testing private methods

⁉️ How to test the private or protected methods?

💭 You shouldn't test private methods! we are only testing the API of a class (aka public members)

❔ Does it mean that we should test against Interfaces?

Reasons

Private methods are participating to be an actual part of the implementation details of a class, which can be changed at anytime from one version to another. but public members would stay the same!
Hence, if you tested against private members your tests will be coupled with implementation detail.

Code Coverage

⁉️ How do we know if we have enough tests?

Well, you can make use of a code coverage tool that is mainly were designed to

Scale your code
Answer that question by telling what parts of our code that's not fully covered by tests

Available Tools

Visual Studio Enterprise Edition
Resharper Ultimate, Dot Cover

Dot Cover is a unit test runner

NCover

Resources

Unit testing for C# developers, by Mosh Hamedani

The Branch & Merge Game

Mohamed Halawa — Thu, 29 Jul 2021 17:05:49 +0000

What is Version Control?

Version control is a system that allows you to keep track of your work and helps you to easily explore the changes you have made no matter what are you changing data, coding scripts, notes, etc. any file in general.

It also allows the collaboration between developers on a single project easily through branching & merging.

Benefits Of Version Control

Makes it easy for you to keep track of collaborative and personal projects - all files necessary for certain analyses can be held together and people can add in their code, graphs, etc.
As the projects develop. each file being tracked by git has a history, making it easy to explore the changes that occurred to it at different time points.
Easily navigate among the many versions of the files you create
Enables reviewing other people’s code and also the collaborative code review for collaborative projects.

Version Control Systems

Our main focus in this article is Git as version control. But, we have to mention other available solutions for version control that are being used widely in Enterprise projects and Individual One.

Git — Most Popular & Used among the Enterprise and Individuals
AWS Code Commit
Azure DevOps Server (TFS)
Subversion (SVN)

There are many solutions for version control, but I've mentioned the popular ones according to the G2 Survey.

The Way Back Machine — Before Version Control

An obvious question a 21st-century developer might ask, How did people develop software before git or version control?

As a 21st-century developer, I made very tiny research trying to answer that question and most of them seem to have a common way of doing "Version Control" which was a Shared Drive. It's either mapped to your pc through a network or being accumulated on a single portable hard disk.

source: http://www.dev.to

Disclaimer: I tried to find a way to contact Mr. Douglas to ask his permission to mention his words in this SS but I failed.

Was it the only way of doing that, copy & paste on a shared hard drive? No, they used what is so-called tarball to version their software which was mainly used by GNU to deliver their open-source software.

A tarball is a snapshot of one particular moment in the application development history along with all the necessary files to configure, build, and install the application easily.

Why Git?

Aside from the fact that it's the most commonly used version control system, It has several advantages. So let's highlight the most epics or features that make it a good-to-go choice especially according to SVN.

Git utilizes multiple repositories: a central repository and a series of local repositories which are exact copies of the central repository complete with the entire history of changes.
Git has a staging area. This just means that if you made 100 new changes to your code, you can break these 100 changes into 10 or 20 or more commits each with their own comments and their own detailed explanation of what just happened!
It’s faster to commit.
- Because you commit to the central repository more often in SVN, network traffic slows everyone down.
- Whereas with Git, you’re working mostly on your local repository and only committing to the central repository every so often.
No more single point of failure.
- With SVN, if the central repository goes down or some code breaks the build, no other developers can commit their code until the repository is fixed.
- With Git, each developer has their own repository, so it doesn’t matter if the central repository is broken. Developers can continue to commit code locally until the central repository has been fixed, and then they can push their changes.
It’s available offline. Unlike SVN, Git can work offline, allowing your team to continue working without losing features if they lose connection.
It’s open-source and cross-platform.

Hey! I guess you forgot to mention that SVN repos are far bigger in size than Git! = mmm, Nope I didn't forget But:

This claim is actually a Myth! they are close in size since they both are using a delta compression algorithm.

I'm not trying to compare Git vs SVN here, it's not the purpose of that article!

A Break!

By reaching this point, you might consider taking a 5-minutes break!

What is a repository?

A repository is a special type of directory that contains all of your project's files and each file's revision history.

With Git, that repository must contain a .git hidden directory that holds all information that Git needs to: keep track of changes, maintain history, commits, remote repository information to push to, .. and so on. Meaning, if you delete the .git directory, then you delete your project’s history.

So why a repository is a special type of directory again? simply because it contains the .git directory.

A repository can hold any type of files and multiple directories. By default, it will keep track of all changes that affect all the files and maintain their history, but you can choose to ignore some files or directories that you believe are not important to exist in the remote repository -being hold by a Git service provider like GitHub- by listing these files or directories in the .gitignore file.

What is branching?

Branching means you diverge from the main line of development and continue to do work without messing with that mainline. In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects.

What is a git branch?

A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you start making commits, you’re given a master branch that points to the last commit you made. Every time you commit, the master branch pointer moves forward automatically.

The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. and Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can entirely change your development.

The “master” branch in Git is not a special branch. It is exactly like any other branch. The only reason nearly every repository has one is that the git init command creates it by default and most people don’t bother to change it.

The Branching Strategy

What is meant by a branching strategy?

A “branching strategy” refers to the strategy a software development team employs when writing, merging, and shipping code in the context of a version control system like Git.

Why do we need a branching strategy?

Have you ever wondered how to manage and maintain your remote repository in the case of a team, not individuals, even multiple teams? how would you handle the changes? make sure that the remote repository is always updated? how would you deliver certain features and ignore others?

These issues are solved by making what is so a branching strategy but don't panic there are existing strategies for general purpose usage, check branching flows for fast-forward.

A branching strategy also ensures everyone on the team is following the same process for making changes to source control. The right strategy enhances collaboration, efficiency, and accuracy in the software delivery process, while the wrong strategy (or no strategy) leads to hours of lost effort.

Our Goal

The goal of any branching strategy is to solve the previous problem and to enable teams to work together on the same source code without trampling on each other. if you achieved that you've simply made a working strategy!

Considerations

There are several things to consider handling while designing a branching strategy, here are the common issues

Typical development workflow

The typical day-to-day flow includes normal changes that developers make to the code. These changes are ordinary in terms of size and complexity for your codebase and, generally, will make up the bulk of all the changes your developers make. Since this flow will be used the most frequently, your strategy here must ensure proper coordination among the developers and support all relevant policies such as automated testing, pull requests, and deployments.

Emergency hotfixes

An emergency hotfix is when a particular incident or issue has been expedited to deal with some emergent situation, normally bug fixes. Your flow must account for a developer who needs to make an urgent change and get it all the way through your process and into production while still aligning with your typical development workflow.

Small vs. large changes

As the industry has evolved, the emphasis on developers working on smaller changes and limited batch sizes has increased due to the broader use of flow-based delivery practices. However, there are still times when you must make large, complex changes, and your branching strategy must accommodate those situations.

Standard vs. experimental changes

Developers feel greater certainty about how standard code changes will perform than with experimental code changes. For example, if you’re evaluating a new library or framework, you may feel uncertain about how well it integrates with your codebase. In that case, your change may or may not actually go to production but still needs to be shared with other developers. Your branching strategy must account for these types of experimental changes.

Common types of branches

1. Main branch

Every Git repository has a main (also referred to as mainline or the master branch). When a Git repository is created, the main exists automatically as the implicit first branch. The use of a main and the timing of changes landing on it vary depending on the exact branching strategy being used. In main-based development, the main is the central branch to which all developers send their code changes.

2. Development branch

The development branch is a long-lived feature branch that holds changes made by developers before they’re ready to go to production. It parallels the main and is never removed. Some teams have the development branch correspond with a non-production environment. As such, commits to the development branch trigger test environment deployments. Development and main are frequently bidirectionally integrated, and it’s typical for a team member to bear the responsibility of integrating them.

3. Release branch

A release branch can be either short-lived or long-lived depending on the strategy. In either case, the release branch reflects a set of changes that are intended to go through the production release process.

4. Feature branch

A feature branch can be short- or long-lived depending on the specific branching flow. The branch often is used by a single developer for only their changes, but it is possible to share it with other developers as well. Again, the branching strategy will determine how exactly you define a “feature branch”.

5. Hotfix branch

A hotfix branch is a branch that’s used generally to hold changes related to emergency bug fixes. They can be short-lived or long-lived, though generally, they exist as long-lived branches split off from a release branch. They tend to be more common in teams with explicitly versioned products, such as installed applications.

Popular Branching flows

GitFlow

GitFlow was introduced by Vincent Driessen in 2010 to share insight into the use of Git for source control as its use became more widespread. GitFlow relies essentially on every type of branch that was discussed previously with the bulk of the development workflow centering on the long-lived development branch as a shared integration branch for all the developers. The main branch, in this case, essentially reflects a history of all the changes that have gone to production.

GitHub Flow

GitHub Flow was popularized by GitHub as a simpler alternative to GitFlow. It calls for the following workflow:

The main branch is always releasable, and in fact, releases are generally done directly from it.
Each developer creates a new branch, the feature branch, for their changes from the main branch.
Feature branches can be deployed to a testing environment for verification or pushed directly to the main branch and deployed to a non-production environment from there.
A short-lived release branch may be used off the main branch to prepare for and execute a release.

Challenges

Both of these branching strategies can work for the right environment, but they have similar downsides. The biggest downside is neither flow adequately supports Continuous Integration. And Continuous Integration is becoming an essential modern development practice. By relying on feature branches, it’s too easy to focus on the benefits of change isolation and ignore the costs. Instead, a better strategy would support Continuous Integration, wherein developers integrate code regularly (i.e., at least every day). Fortunately, there is a branching strategy able to meet all these needs: trunk-based development.

What's Next?

This is not an in-detail article, it's a high-level one that allows people to discover the missing parts in their strategy. and since I've started that just to enable reaching the point where we can set up our version control system in a way that would support Continuous Integration. my next writing will be dedicated to Trunk-based Development along with any other alternative technique that I might find out while researching.

For now, thanks for giving me your precious time. I'll gladly accept comments that aim to enhance the content quality or correct mistaken info that I wrote here.

Resources

A Short Guide to Console Messages

Mohamed Halawa — Fri, 19 Feb 2021 13:18:50 +0000

Curious to know how to log different types of messages in console? Okay Just follow up with me..

There are 6 types of messages that Chrome DevTools Console supports:

Information
Warning
Error
Table
Group
Custom Message

Information

It can be done via console.log(<value>) function

console.log("[INFO]: You've Inserted 1 row in the database!");

Warning

It can be done via console.warn(<value>) function

console.warn("[WARNING]: You're about to leave this page !");

You can check it's Stack Trace by pressing the left-most little cursor ▶️

Error

It can be done via console.error(<value>) function

console.error("[Error]: This kind of operations requires a Quantum Machine !");

Table

It can be done via console.table([<Array of Objects>]) function

Example

let _humankind = [
    {
        Id: '0',
        Type: 'homosapien',
        Name: 'Uncle Bob'
    },
    {
       Id: '1',
       Type: 'neanderthal',
    },
    {
       Id: '2',
       Type: 'denisovan',
       Name: 'Donald Trump'
    }
];
console.table(_humankind);

Group

console.group(<label>) console.groupEnd(<label>) both are used to achieve it!

let humanGroup= 'List of Human:';

// Begin the group
console.group(humanGroup);
console.info('homosapien');
console.info('neanderthal');
console.info('denisovan');
// Necessary to end the group

console.groupEnd(humanGroup);

[Optional Section] Further Explanation

Store a the string that represents the group title (label) into a variable to make it easy recalling it
E.G.let label = 'List of Human:';
Start the group by Invoking console.group(label) or console.group('List of Human:')`

We don't need the second invocation because we already stored the title in the label variable !

Add elements to that group by passing it to the console.info(<content>).
Finally, Claim the end of the group using console.groupEnd(label) or console.groupEnd('List of Human:')`

That's exactly why we defined the label variable:

it's easier to recall

Avoid probable spelling mistakes !

Custom Message

Ever wondered How facebook style the stop console message whenever you try to inspect it?

Well, it's possible via console.log() but you have to:

Add a preceding %c to mark it as a custom Log.
Pass your css rules to style the content as a second argument.

So the final Invocation form is: console.log('%c<content>',styleRules);

const spacing = '0.5rem';
const style = `
        padding: ${spacing};
        background-color: yellow;
        color: blue;
        font-weight: Bold;
        border: ${spacing} solid red;
        border-radius: ${spacing};
        font-size: 2em;
`;
console.log('%cThis is a Custom Log !', style);

DEV Community: Mohamed Halawa

The Essential Unit Testing Techniques, Part 1

Testing strings

1. Using $"{}" format or string.Format

2. Using Does.StartWith, Does.EndWith, Does.Contain Methods

3. Using Regex

Testing arrays and collections

1. Testing if an Array has any elements

2. Testing the count of a collection

3. Testing if a collection contains X

4. Testing the order of a collection

5. Testing the uniqueness of a collection's elements!

Testing Methods

Testing return type

Is.TypeOf<>()

Is.InstanceOf<>()

Testing void methods (commands)

Testing methods that throw an exception

Testing methods that raise an event

Testing private methods

Reasons

Code Coverage

Available Tools

Resources

The Branch & Merge Game

What is Version Control?

Benefits Of Version Control

Version Control Systems

The Way Back Machine — Before Version Control

Why Git?

A Break!

What is a repository?

What is branching?

What is a git branch?

The Branching Strategy

What is meant by a branching strategy?

Why do we need a branching strategy?

Our Goal

Considerations

Typical development workflow

Emergency hotfixes

Small vs. large changes

Standard vs. experimental changes

Common types of branches

1. Main branch

2. Development branch

3. Release branch

4. Feature branch

5. Hotfix branch

Popular Branching flows

GitFlow

GitHub Flow

Challenges

What's Next?

Resources

A Short Guide to Console Messages

Information

Warning

Error

Table

Example

Group

[Optional Section] Further Explanation

Custom Message

1. Using `$"{}"` format or `string.Format`

2. Using `Does.StartWith`, `Does.EndWith`, `Does.Contain` Methods

`Is.TypeOf<>()`

`Is.InstanceOf<>()`