Category: Code

When you test, either by writing code or performing manual testing, you do so because you want to ensure that your software works as intended. This unit focuses on writing code that tests various parts of your application code. The test code won’t ship with the application code. Think of test code as scaffolding that supports the software development process throughout your program’s lifetime.

Let’s start by defining testing with some examples, before we dive into the concepts.

The testing process

Testing involves a series of test methods that run against your product code, and return a pass or fail result. The result is based on certain criteria that is asserted. Test results appear in a list of red “x” marks to represent failing tests, and green “✔” marks to represent passing tests. These symbols make it easy to assess what functionality is working or not at a glance.

Test method definition

Tests are very much like regular methods. They’re organized within test classes, have method signatures, and accept parameters. Tests reference and call your product code (another way of saying your non-test code), and compare how it behaves to an expected outcome.

[TestMethod]
public void AddTest()
{
    // Arrange
    var calculator = new Calculator();

    // Act
    var actual = calculator.Add(1, 1);

    // Assert
    Assert.AreEqual(2, actual);
}

In the preceding code, the product code is the Calculator class and its Add() method. The comparison happens when calling Assert.AreEqual(2, actual). This pattern is something you find in most, if not all, test methods. Here’s how this test would appear in Visual Studio: 

One difference between tests and product code is they don’t run as part of your app’s normal function. So instead of using F5 (or the large green run button at the top of your development environment) to run as you would your app, you choose which tests to run. You can make this choice through Visual Studio Test Explorer or other helpful editor tools. Tests are there for support but because they aren’t shipped with the app, they run independently like their own app.

 

How can tests help prevent regressions in functionality?

Remember the phone number bug from the scenario mentioned in the introductory unit? As soon as new code was added to accept international phone numbers, the function for adding domestic phone numbers broke! A test using domestic phone numbers as input might have caught this behavior change sooner. It would have tested not only the new functionality for international numbers, but also the old functionality for domestic phone numbers.

As we implement new code, it might not always occur to us what old scenarios could be affected by new changes. The phone numbers are a simple example, but imagine apps with hundreds of different input formats. Tests make it easy for all variations of the old behavior to be checked with a simple test run.

 

Why we test

Testing can be a powerful tool to improve the quality, architecture, and overall health of a code base. In this unit, we discuss some of the ways that testing can have a positive impact in the software industry.

Validate code changes and quality

Any successful software tends to grow in functionality and behavior. Sometimes it can grow beyond what the creators ever imagined to support more scenarios and customer requests. As functionality grows, it can become more difficult for a single developer to remember all the functionality it contains or keep track of how to preserve that functionality.

Tests not only keep track of the different capabilities of a program, but can also continue to check that the old functionality didn’t break as new code is added. A fundamental purpose of testing is validating that code changes don’t break existing functionality, and ensuring that newly added code will continue to work as expected even with future changes.

Tests can help catch bugs before you even check in your code changes. It’s a best practice to run tests before major steps in your development cycle. This final check allows you to improve your code quality so your users don’t have to report that something broke in your latest update. It’s much nicer to catch bugs while you’re still developing the code, rather than when you’re in the middle of deploying your app or when the app is in production with customers using it! Catching bugs early in the development cycle saves time and money.

Industry examples

A good example of the power of testing can be found in the C# compiler itself! Millions of developers write code in C# every day. Have you ever wondered how tools can keep adding language features and releasing new language versions without breaking existing code? Tests provide a final set of hundreds of thousands of checks to make sure previous scenarios still work. There’s no way one person, or even one team could remember all those scenarios.

It’s especially true when you consider that the C# compiler is open source, and accepts contributions from a world-wide community of developers. The C# compiler team can accept changes from the community with confidence, in part because of the checks that testing provides. Testing is helpful for individuals and at the team level, allowing you to scale your product and your team as they grow.

Effects on architecture

Testing can also force some architecture improvement. You can’t test small parts of your code if it’s structured as one gigantic method. Tests can help you break up all the functions of your code into more modular components. Tests can reduce repetition, improve stability, and even make your code easier to read and navigate.

For example, if you’re using the same logic in many places throughout your app and then realize there’s a problem with it, you’ll have to find and update all the places you used it. Instead, if you use a method, you only need to update it once, because even though that method is called many times throughout your app, you only wrote the logic once in the body of the method.

Testing helps you pause and consider if you’re repeating the same logic multiple times and could use a method instead. It provides developers a chance to restructure code for the best reusability and stability going forward.

Code coverage and code health

Code coverage is a metric that indicates how much of an app’s production code is covered by tests. It indicates if tests actually exercise all the product code, including branching logic and method overloads. Code coverage can give a basic idea of what areas need more testing. Visual Studio even has tools that can highlight what lines are covered by tests, and what lines aren’t, in your editor.

Tracking the code coverage percentage over time can give you an idea if the new code being added to your repository has tests. If new code isn’t being tested, it might be an indication that the repository is building up technical debt. While code coverage is useful, it’s not an ultimate indication of repo health. It should only be one of many factors used to assess the health of a repo.

Different code coverage engines can calculate coverage differently, and many programs can appear to have low coverage, despite being well tested. For example, heavily testing certain methods that have high use, and ignoring other methods, might actually be the right thing to do for a particular repo. We wouldn’t encourage every repo to try to achieve 100 percent code coverage, because that isn’t a practical investment for many businesses.

We’ve also featured the Best Web Hosting Services of 2023.

There’s much debate about whether or not there’s a universal code coverage percentage that repositories should aspire to. For now, we believe the best guidance is to judge on a case-by-case basis, and not arbitrarily hold your team to a number without a deeper discussion.

GitHub Actions is a feature of GitHub that allows users to automate tasks directly on GitHub. It provides a way for users to easily create custom automated workflows or “Actions” that can be triggered by various events such as pushing code to the repository, creating or editing an issue, or manually triggering the workflow. These workflows can be used to build, test, package, release, and deploy applications and software, as well as automate other types of tasks.

Here, we’ll introduce GitHub Actions and workflows. You’ll learn the types of actions you can use and where to find them. You’ll also look at examples of these types of actions and how they fit in a workflow.

What is GitHub Actions?

GitHub Actions are packaged scripts to automate tasks in a software development workflow in GitHub. You can configure GitHub Actions to trigger complex workflows that meet your organization’s needs; each time developers check new source code into a specific branch, at timed intervals, or manually. The result is a reliable and sustainable automated workflow, which leads to a significant decrease in development time.

 

GitHub decreases time from idea to deployment

GitHub is designed to help teams of developers and DevOps engineers build and deploy applications quickly. There are many features in GitHub that enable this, but they generally fall into one of two categories:

• Communication: Consider all of the ways that GitHub makes it easy for a team of developers to communicate about the software development project: code reviews in pull requests, GitHub issues, project boards, wikis, notifications, and so on.
• Automation: GitHub Actions lets your team automate workflows at every step in the software-development process, from integration to delivery to deployment. It even lets you automate adding labels to pull requests and checking for stale issues and pull requests.

When combined, these features have allowed thousands of development teams to effectively decrease the amount of time it takes from their initial idea to deployment.

Use workflow automation to decrease development time

In this module we’ll focus on automation, so let’s take a moment to understand how teams can use automation to reduce the amount of time it takes to complete a typical development and deployment workflow.

Consider all of the tasks that must happen after the code is written, but before the code can be reliably used for its intended purpose. Depending on your organization’s goals, you’ll likely need to perform one or more of the following tasks:

• Ensure the code passes all unit tests
• Perform code quality and compliance checks to make sure the source code meets the organization’s standards
• Check the code and its dependencies for known security issues
• Build the code integrating new source from (potentially) multiple contributors
• Ensure the software passes integration tests
• Version the new build
• Deliver the new binaries to the appropriate filesystem location
• Deploy the new binaries to one or more servers
• If any of these tasks do not pass, report the issue to the proper individual or team for resolution

The challenge is to do these tasks reliably, consistently, and in a sustainable manner. This is an ideal job for workflow automation. If you’re already relying on GitHub, you’ll likely want to set up your workflow automation using GitHub Actions.

Where can you find GitHub Actions?

GitHub Actions are scripts that adhere to a yml data format. Each repository has an Actions tab that provides a quick and easy way to get started with setting up your first script. If you see a workflow that you think might be a great starting point, just select the Configure button to add the script and begin editing the source yml.

 

However, beyond those GitHub Actions featured on the Actions tab, you can:

• Search for GitHub Actions in the GitHub Marketplace. The GitHub Marketplace allows you to discover and purchase tools that extend your workflow.
• Search for open-source projects. For example, the GitHub Actions organization features many popular open-source repos containing GitHub Actions you can use.
• Write your own GitHub Actions from scratch. Furthermore, if you want, you could make them open source, or even publish them to the GitHub Marketplace.

Using open-source GitHub Actions

Many GitHub Actions are open source and available for anyone who wants to use them. However, just like with any open-source software, you need to carefully check them before using them in your project. Similar to recommended community standards with open-source software, such as including a README, code of conduct, contributing file, and issue templates, just to name a few, you can follow the following recommendations when using GitHub Actions:

• Review the action’s action.yml file for inputs, outputs, and to make sure the code does what it says it does.
• Check if the action is in the GitHub Marketplace. This is a good check, even if an action does not have to be on the GitHub Marketplace to be valid.
• Check if the action is verified in the GitHub Marketplace. This means that GitHub has approved the use of this action. However, you should still review it before using it.
• Include the version of the action you’re using by specifying a Git ref, SHA, or tag.

Two types of GitHub actions

There are two types of GitHub actions: container actions and JavaScript actions.

With container actions, the environment is part of the action’s code. These actions can only be run in a Linux environment that GitHub hosts. Container actions support many different languages.

JavaScript actions don’t include the environment in the code. You’ll have to specify the environment to execute these actions. You can run these actions in a VM in the cloud or on-premises. JavaScript actions support Linux, macOS, and Windows environments.

The anatomy of a GitHub action

Here’s an example of an action that performs a git checkout of a repository. This action, actions/checkout@v1, is part of a step in a workflow. This step also builds the Node.js code that was checked out. We’ll talk about workflows, jobs, and steps in the next section.

steps:
- uses: actions/checkout@v1
- name: npm install and build webpack
run: |
npm install
npm run build

Suppose you want to use a container action to run containerized code. Your action might look like this:

name: "Hello Actions"
description: "Greet someone"
author: "[email protected]"

inputs:
MY_NAME:
description: "Who to greet"
required: true
default: "World"

runs:
uses: "docker"
image: "Dockerfile"

branding:
icon: "mic"
color: "purple"

Notice the inputs section. Here, you’re getting the value of a variable called MY_NAME. This variable will be set in the workflow that runs this action.

In the runs section, notice you specify docker in the uses attribute. When you do this, you’ll need to provide the path to the docker image file. Here, it’s called Dockerfile. We won’t get into the specifics of Docker here, but if you would like more information, check out the Introduction to Docker Containers.

The last section, branding, personalizes your action in the GitHub Marketplace if you decide to publish it there.

You can find a complete list of action metadata at Metadata syntax for GitHub Actions.

What is a GitHub Actions workflow?

A GitHub Actions workflow is a process that you set up in your repository to automate software-development lifecycle tasks, including GitHub Actions. With a workflow, you can build, test, package, release, and deploy any project on GitHub.

To create a workflow, you add actions to a .yml file in the .github/workflows directory in your GitHub repository.

In the exercise coming up, your workflow file, main.yml, will look like this.

name: A workflow for my Hello World file
on: push
jobs:
build:
name: Hello world action
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- uses: ./action-a
with:
MY_NAME: "Mona"

 

Notice the on: attribute. This is a trigger to specify when this workflow will run. Here, it triggers a run when there’s a push event to your repository. You can specify single events like on: push, an array of events like on: [push, pull_request], or an event-configuration map that schedules a workflow or restricts the execution of a workflow to specific files, tags, or branch changes. The map might look something like this:

on:
# Trigger the workflow on push or pull request,
# but only for the main branch
push:
branches:
- main
pull_request:
branches:
- main
# Also trigger on page_build, as well as release created events
page_build:
release:
types: # This configuration does not affect the page_build event above
- created

 

An event will trigger on all activity types for the event unless you specify the type or types. For a comprehensive list of events and their activity types, see: Events that trigger workflows in the GitHub documentation.

A workflow must have at least one job. A job is a section of the workflow that will be associated with a runner. A runner can be GitHub-hosted or self-hosted, and the job can run on a machine or in a container. You’ll specify the runner with the runs-on: attribute. Here, you’re telling the workflow to run this job on ubuntu-latest.

Each job will have steps to complete. In our example, the step uses the action actions/checkout@v1 to check out the repository. What’s interesting is the uses: ./action-a value, which is the path to the container action that you build in an action.yml file. We looked at the contents of an action.yml file in the What is GitHub Actions? section.

The last part of this workflow file sets the MY_NAME variable value for this workflow. Recall the container action took an input called MY_NAME.

For more information on workflow syntax, see Workflow syntax for GitHub Actions

GitHub-hosted versus self-hosted runners

We briefly mentioned runners as being associated with a job. A runner is simply a server that has the GitHub Actions runner application installed. In the previous workflow example, there was a runs-on: ubuntu-latest attribute within the jobs block, which told the workflow that the job will run using the GitHub-hosted runner that is running in the environment ubuntu-latest.

When it comes to runners, there are two options to choose from: GitHub-hosted runners or self-hosted runners. If you use a GitHub-hosted runner, each job runs in a fresh instance of a virtual environment that is specified by the GitHub-hosted runner type you define, runs-on: {operating system-version}. With self-hosted runners, you need to apply the self-hosted label, its operating system, and the system architecture. For example, a self-hosted runner with a Linux operating system and ARM32 architecture would look like the following, runs-on: [self-hosted, linux, ARM32].

Each type of runner has its benefits, but GitHub-hosted runners offer a quicker, simpler way to run your workflows, albeit with limited options. Self-hosted runners are a highly configurable way to run workflows in your own custom local environment. Self-hosted runners can be run on-premises or in the cloud. You can also use self-hosted runners to create a custom hardware configuration with more processing power or memory to run larger jobs, install software available on your local network, and choose an operating system not offered by GitHub-hosted runners.

GitHub Actions may have usage limits

GitHub Actions has some usage limits, depending on whether your runner is GitHub-hosted or self-hosted and your GitHub plan. For more information on usage limits, check out Usage limits, billing, and administration in the GitHub documentation.

Don’t forget to tell us about your favorite GitHub features in the comment below.

Read More: DigitalOcean Promo Code 2023: $200 credit for 60 days