Forem: Lula Leus

An Engineer's Toolkit for continuous upskilling

Lula Leus — Sun, 27 Aug 2023 16:50:32 +0000

Introduction

Software engineering is ever-evolving. The best practices and tools available for developers today differ from those of just 5 years ago. And they will similarly differ from what will be available in the next 5 years.

In this shifting landscape, one constant is the engineers. Those that are building software today are likely to continue building software in 5 years time. In order to do so successfully, we should know the new tools and promote the usage of best practices of the day. But how can we keep our knowledge up-to-date and our skills relevant all the time? The answer is simple: we must become "lifelong learners" out of necessity.

In this article, I'll detail my approach to continuous learning and upskilling in software engineering. I will spotlight learning resources that I find most helpful. I'll also share a strategy to track learning progress and offer advice on how to keep going when learning doesn't have strict deadlines.

Choosing Learning Materials to Use

Newsletters

Newsletters are curated collections of recent engineering news, articles, and open-source projects. They are great for answering the question "What's new out there?". I am a regular reader of the following three newsletters:

InfoQ Weekly: A comprehensive roundup of software engineering news and articles. It is worth noting that all articles mentioned there have almost academic qualities air to them. Heavy on knowledge, light on engaging storytelling, emojis or jokes.
Awesome Go Weekly: Since Go is my main programming language at work, I like to stay updated with the Go development.
ByteByteGo: A bite-sized system design and architectural articles. System design is a fascinating topic. It is also a topic in which most engineers are rarely directly involved at work.

My main reason for reading these newsletters is to get up-to-date with a constant flow of news and identify new emerging topics I can explore in more depth later.

It's easy to get carried away and subscribe to numerous newsletters. But remember, reading newsletters, unlike subscribing, demands time. It's better to read and benefit from a couple of weekly newsletters than to be overwhelmed with many, leading you to question your subscription choices.

Articles

I primarily come across articles I want to read either through recommendations in newsletters or while searching for answers to specific, well-defined questions.

Articles are useful resources for following use cases.

Quick broad Overviews: An introductory overview of a topic. Take, for example, "A Framework for Prioritizing Tech Debt". This article provides a clear understanding of what tech debt is and presents a possible structured approach to deciding whether to eliminate it must be a priority. You do not need specific pre-existing knowledge to get value out of the article.
Detailed Exploration of specific issue: Intensive focus on specific and very narrowly scoped issue. For example, the article "User or *User - Do We Need Struct Pointers Everywhere?" dives into nuances of passing structs either by value or by reference in Golang. You need a lot of pre-existing knowledge of Go and its type system in order to get value out of the article.

Articles help you to go very broad or very deep once you identified the topic

Books

Books offer a huge amount of knowledge on their subjects. One good book can take you on a journey from zero knowledge to expert-level knowledge on the subject.

I divide all engineering books into two categories: "Practical" and "Conceptual".

Practical Books usually contain many executable code examples. The books teaching programming languages are the most obvious examples of "practical" books. For example, Head First Kotlin contains many executable examples, as well as many pen-and-paper exercises for the readers.

Conceptual Bookslean heavily on illustrative diagrams and are sparse on executable code examples. Consider Software Architecture: The Hard Parts as an example. Getting familiar with concepts like "Architectural Decomposition" or "Distributed transactions" is vital for being a knowledgeable engineer, but it is not something you can immediately practice by running a code example.
Conceptual books are perfect for reading on the go when you are away from your laptop. Think commute or periods of waiting. Got a spare 15 minutes and a seat? That's a reading opportunity right there.

When it comes to picking the next book, it can be challenging. Sure, there are the well-known engineering "must-reads" like Clean Code and Domain Driven Design. Their reputation precedes them, and they certainly deserve your time. But what about the latest releases? I have a few suggestions.

Social media, particularly Twitter, can help. If you follow industry leaders or fellow engineers, you'll inevitably come across book recommendations. A Social media osmosis in action.
Job-based initiatives like "engineering libraries" in the office or a Slack channel functioning like a book club. Both can provide valuable and relevant reading suggestions.
Occasionally browsing new releases sections of major publishers such as O'Reilly, Manning, and Packt can be a direct source for filling your to-read list.

Be conservative in estimating how many books you can read in a year. If not sure, aim for 2–3 books. Technical books aren't easy to read. While I might breeze through a novel in two weeks, I never managed to do the same with an engineering book.

Video Courses

They combine auditory and visual learning, distinguishing them from text-based articles and books.

Front End Masters excel in their 'code-along' recorded workshops on various topics, often beyond the scope of front-end development. For example, The Rust Programming Language is one of such courses.
Udemy has a huge number of courses, but they can be hit or miss depending on the instructor. One example of a hit is a bestselling course Pragmatic System Design.
LinkedIn Learning curates a broad spectrum of courses catering to various professional domains.

When on the hunt for a new course, I usually skim through the platforms mentioned above, searching for specific topics related to my current learning area of interest, which can be something like "learning intermediate and advanced SQL" or "Event-driven architecture".

Conference Talks

Most of the talks presented at any given tech conference become available online a few weeks or months after the event. Conference talks have a dual role of educating and entertaining. They are valuable for broadening your knowledge horizons. As with any learning material, not all talks are equally interesting. While some presentations shine due to the excellent combination of visuals and narration, others might fall short when watched in isolation, without the context of the tech conference at which they were presented.

My recently watched favorites include

Visualizing software architecture with the C4 model - Simon Brown, Agile on the Beach 2019 and - Debugging Treasure Hunt - Suzy Mueller, GopherCon 2021.

To curate a list of talks for future viewing, I visit websites like confs.tech or dev.events, focusing on Backend engineering and Golang conferences. From there, it's a dive into individual conference websites to choose the talks to my "watch later" list. I give preference to conferences with shorter 30-minute talks over longer 50-minute sessions. As I think they provide better value to time ration.

Hands-on Project

Active practice is an essential form of learning. While acquiring information is vital, applying it ensures that it's converted into a skill that stays with you.

Sometimes, the newly acquired knowledge can be immediately used in daily engineering tasks at work. Unfortunately, it is not always the case. So you need to find other ways to practise.

In my early days as an engineer, I frequently worked on mini projects to improve and practise my skills. I still do such mini-projects, but less often. However, I do recommend it as the most straightforward way to practice, especially for junior engineers.

At the current stage of my career, activities such as writing articles or preparing engineering talks also serve as practical, hands-on learning for me. I reinforce my own knowledge by sharing it with others.

Finding Time

First, stating the obvious, finding time for studying when you have a full-time job and various outside-of-work responsibilities is hard. And It will never be easy. But it is necessary as the key to successfully learning anything lies in continuity. Regular, even if brief, learning intervals can lead to significant progress over time.

Some employers recognize the value of continuous learning and upskilling and have initiatives like "Half-Day Learning Fridays". If you're fortunate to work for such an employer, it's a boon. However, if not, you're in the majority, and it's up to you to carve out time for personal upskilling.

Taking myself as an example, I dedicate 6–12 hours weekly, outside of work, to learning. This might seem like a big number, but it doesn't feel like a chore most of the time, thanks to my general passion for learning.

I've found that bundling these hours over 3 days from Friday to Sunday - works best for me. My previous attempts to study in the evenings after work often made me miserable. Attempts to wake up early and study before work resulted in me being sleepy and starting the work day while already tired.

Choosing your learning days and hours around what feels most sustainable for you is essential. There's no one-size-fits-all approach. Remember, the continuous learning journey is about personal growth at your own pace, free from external timelines.

Tracking Progress

With tangible goals like "preparing for a job interview", you have a clear objective and a deadline. However, when you're aiming "to stay reasonably up-to-date with the state of software engineering", the goal is vague, and there's no set timeframe to achieve it.

To manage the ambiguity of ongoing learning, I came up with the idea of a Learning board on Notion, inspired by a kanban methodology. I've been using my board successfully for the past two years. The board uses columns to represent progress stages and rows for categorizing the learning medium. I want to particularly note that there are no "sprints" on my board. I use the same board for an entire calendar year.

The essential structure of a learning board.

Here's how I interact with my board:
On-the-Fly Updates: Whenever there's a change in the status of a learning item, I move the card. For instance, when I start a video course or finish an article, I update its status.
Weekly Board Check: Every Sunday, I dedicate 20 minutes to review the board. This routine helps in:

Assessing my progress, like how many pages of the current-read book I read this week. Thinking about the upcoming week and picking out items I plan learn.
Evaluating the "No status" column, either promoting items to "Not started" or removing ones that no longer align with my interests.
Hunting for the new materials. if I have some topic on my mind that I want to learn more about. Or if my "No status" column looks particularly empty.

The learning board offers a clear snapshot of my activities. It helps me plan what I want to learn and how. It also provides a log of what I've learned so far in the current calendar year.

If you like my learning board approach, you can duplicate it as a Notion template and create your own unique learning board based on it.

Conclusion

I believe that commitment to continuous learning and upskilling is a non-negotiable requirement for being a great software engineer. So, crafting an efficient and structured approach to learning is crucial. Through trial and error, I've arrived at the method shared above.

Although my learning process is already well-defined, I'm always looking for ways to refine it even further. I welcome any suggestions or feedback you can give me in the comments.

Top 3 Design Patterns for a Large Go Codebase

Lula Leus — Wed, 05 Jul 2023 20:40:12 +0000

Introduction

Design patterns are often considered to be fundamental knowledge every good software engineer should possess. Maybe it is true. However, not all theoretical knowledge is useful for day-to-day work.

I felt uncertain about the applicability of design patterns to my day-to-day work in a large microservice-based codebase, servicing millions of users. So I decided to investigate.

I don’t aim to describe all classical software design patterns. I concentrate on the top 3 design patterns, the usage of which I notice regularly. I’ll explain what particular real-world problem each of these patterns solves.

A very brief history of design patterns

Let’s refresh our knowledge of how software engineering design patterns came about. In 1994, four authors — Erich Gamma, John Vlissides, Ralph Johnson, and Richard Helm published a book “Design Patterns: Elements of Reusable Object-Oriented Software”. This book earned the nickname “The Book by the Gang of Four,” later abbreviated to “the GoF book”.

The GoF book contained 23 patterns categorized into three groups: Creational, Structural and Behavioural patterns. The examples for the book were written in C++ and Smalltalk. As could be expected, the described patterns were influenced by these specific languages and by software engineering needs of the time. However, the concept of patterns proved to be enduring.

Today, we still refer to these 23 patterns grouped into three categories as the classic software design patterns. Example implementations for all these patterns are written in all the popular languages, including an implementation in Go. The latest is of particular interest to me since I mostly work with Go myself.

Why use design patterns?

So design patterns exist, but why use them? They help engineers avoid reinventing the wheel when tackling commonly known or repetitively recurring problems. Additionally, design patterns help to communicate ideas between software engineers efficiently.

Knowledge of patterns may help engineers in the process of getting accustomed to an unfamiliar codebase too. The codebase, no matter its size, becomes less overwhelming if what happens in it can be mind-mapped with something familiar and universal. Design patterns provide frameworks for such mapping.

Strategy: A plan for clarity and readability

“Strategy: a plan that is intended to achieve a particular purpose”
Cambridge dictionary

In software engineering, Strategy is a behavioural design pattern that allows objects to have a set of interchangeable behaviours and the ability to choose one of them at runtime according to the current needs.

The typical use-case for a Strategy pattern is an endpoint request handler. The handler’s behaviour must differ according to the request parameters, yet the complexity does not warrant separate endpoints for each case.

Let’s consider a microservice called authorisations-report as an example. It has a single endpoint /get-report, which generates well… a report. Different types of reports can be requested, such as authorisation roles, authorisation policies or assignments (connections between users and their authorisations).

The code for this example divided between two packages — handler and report. handler function GetReport calls Build method exposed by the report package and passes to it a requested report type. The report type can be either “roles”, “policies” or “assignments”.

package "handler"

func (h *Handler) GetReport(ctx context.Context, body *reportproto.GetReportRequest) (*reportproto.GetReportResponse, error) {
    // Generate report
    result, err := report.Build(ctx, body.ReportType)
    if err != nil {
        return nil, error
    }

    return &reportproto.ReportResponse{report: result}, nil
}

And here the report package. When Build functions is called, it selects a strategy for report building based on the type provided.

package "report"

func Build(ctx context.Context, reportType string) (Report, error) {
    // We choose strategy to build report
    var reportBuilder reporter
    switch reportType {
    case constants.ReportTypeUsers:
        reportBuilder = allUsersReporter{}
    case constants.ReportTypeRoles:
        reportBuilder = roleReporter{}
    case constants.ReportTypePolicies:
        reportBuilder = policyReporter{}
    default:
        return nil, fmt.Errorf("invalid_report_type: Invalid report type provided")
    }

    report, err := reportBuilder.build(ctx, w)

    return report, err
}

The Strategy pattern is a simple and clean way to create different behaviours without overloading the code with numerous if/else conditions, thereby maintaining clarity and readability.

Facade: a way of communication with 3rd-party service providers.

“Facade (false appearance): a false appearance that makes someone or something seem more pleasant or better than they really are”
Cambridge dictionary

In software engineering, by using a facade, we can hide an inner complexity of an actual entity implementation behind a simplified outer interface, which exposes only methods needed by the external system. This provides a simple and user-friendly interface to communicate with.

In microservices-based architecture, I saw this pattern being used many times for communication with 3rd party services. For example, DocuSign for managing documents or GreenHouse to assist with recruiting. Each facade is an autonomous microservice that bridges internal company services and external 3rd party API. This offers the flexibility to construct generic integrations that can be scaled up and down, monitored like any internal service, etc. I’ll look at microservice hr-system as an example of the facade.

The code example demonstrates one endpoint handler ReadEmployee, responsible for getting employee by ID from external HR system using client.GetEmployee. The employee data is then transformed into a protobuf object shape using marshaling.EmployeeToProto, before being returned to the requester.

package handler

func (h *Handler) HandleGETReadEmployee(ctx context.Context, body *hrsystemproto.GETReadEmployeeRequest) (*hrsystemproto.GETReadEmployeeResponse, error) {
    if body.EmployeeId == "" {
        return nil, validation.ErrMissingParam("employee_id")
    }

    // client is based on Go net/http package and does request to 3rd party system
    employee, err := client.GetEmployee(ctx, body.EmployeeId)
    if err != nil {
        return nil, fmt.Errorf("failed to read employee")
    }

    marshalled, err := marshaling.EmployeeToProto(ctx, employee)
    if err != nil {
        return nil, fmt.Errorf("failed to marshal employee")
    }
    return &hrsystemproto.GETReadEmployeeResponse{
        Employee: marshalled,
    }, nil
}

The use of facades provides a few benefits. Engineers are offered a limited subset of strongly-typed endpoints, where intricacies associated with request authentication, optional parameters, or object transformation are already addressed.

When the need in onboarding new 3rd party integration arises, to build it is becomes a quick and easy task because comprehensive blueprint for doing so already exists.

Fan-out/Fan-in: Leveraging concurrency for getting results faster

“Fan-out: to spread out over a wide area”
The Cambridge dictionary.

This design pattern belongs to the concurrency patterns group and is outside of the The GoF book. However, the pattern is ubiquitous in distributed systems. Hence I want to discuss it.

The concept of this pattern is to divide a data retrieval task into multiple chunks, execute them concurrently, and then aggregate the results.

An array of items, where each item should be processed somehow, is a simple but realistic example. Imagine that the array is very large or processing of items takes a long time (For example, every item produces/requires an HTTP call).

I will look at microservice authorisations-report as an example of the use of the Fan-in/Fan-out pattern. We already discussed this microservice in Strategy design pattern section. Noting prevents the service from implementing more than one design pattern at once.

Let’s say that the service received a request to produce an “assignments” report. In this service domain, assignment means a connection between company employee and authorisations granted to this employee. And assignments report is expected to provide information about all company employees and all authorisations currently granted to them.

Creation of such a report requires a lot of network requests, and doing it sequentially, on employee after employee basis, took around 30 minutes to complete.

Fan-out/Fan-in pattern comes to the rescue. It’s worth noting that in snipped of code, we do not spawn a Goroutine per employee since it would create more than one thousands goroutines and unhealthy spike in requests for all downstream services. We use a semaphore to limit our fanning-out width to 100 goroutines.

func createReportRows(ctx context.Context, employeeProfiles []profile) (map[string]reportRow, error) {
    numOfEmployees := len(employeeProfiles)
    rowsChan := make(chan reportRow, numOfEmployees)
    concurrencyLimiter := semaphore.NewWeighted(100)

    // Fan-out stage, create rows of assignment report concurrenty
    for _, employee := range employeeProfiles {
        // Acquire a "token" from semaphore, block if none available.
        if err := concurrencyLimiter.Acquire(ctx, 1); err != nil {
            return nil, err
        }

        go func(curProfile profile, rowsChan chan<- reportRow, concurrencyLimiter <-chan struct{}) {
            // Release the "token" back to semaphore
            defer concurrencyLimiter.Release(1)

            rowsChan <- newRow(ctx, curProfile)
        }(employee, rowsChan, concurrencyLimiter)
    }

    // Fan-in stage, all created rows go into one data structure
    // As we know the exact number of rows, we can use a simple for loop
    // and wait for all of them to be created and sent to the channel.
    rows := make(map[string]reportRow, numOfEmployees)
    for i := 0; i < numOfEmployees; i++ {
        assignment := <-rowsChan
        rows[assignment.id] = assignment
    }

    return rows, nil
}

Fan-out/Fan-in is one of the most useful and ubiquitous patterns in a modern software engineering landscape because processing things one by one is just not enough.

Recap of Discussed Design Patterns

The demonstrated use of design patterns proves that these patterns are more than theoretical constructs. They are integral to a production codebase and help maintain high coding standards by reapplying established effective patterns for solving recurrent problems.

In addition to classical design patterns, concurrency patterns have become a vital part of contemporary software development. I quickly looked at this group of patterns with the widely used Fan-out/Fan-in pattern.

That’s my take on design patterns that can be applied to software engineers’ day-to-day work. I’ve explored the top 3 from my experience, but the exploration doesn’t stop there. Design Patterns have evolved beyond the original 23 from The GoF, and beyond the addition of concurrency patterns. There are architectural patterns, messaging patterns, and so much more to explore!

Table-driven and individual subtests in Golang: which one to use

Lula Leus — Sat, 06 Aug 2022 11:19:00 +0000

Intro

Unit tests are an essential part of any code base, including the one at my workplace. When an engineer adds a piece of new logic into the codebase, they are expected to add unit tests that will cover, at least, the most common scenarios of the new logic usage. Perhaps with a couple of edge cases as a cherry on the top.

Testing different scenarios is important, but requires writing fairly repetitive tests. Let’s look at approaches Golang offers for this.

Testing packing of a doughnuts box

We’ll look at two different ways to write unit tests in Golang. We will use a playful example of packing a doughnuts box. The flavours of the doughnuts in the examples, are all inspired by Crosstown doughnuts. Let’s look at the code, for which we’ll write tests.

Implementation of a doughnut box

package doughnuts_box

import (
    "fmt"
)

type doughnutsBox struct {
    capacity  int
    doughnuts []string
}

var knownDoughnutTypes = map[string]bool{
    "Matcha Tea":                true,
    "Lime & Coconut (ve)":       true,
    "Home Made Raspberry Jam":   true,
    "Cinnamon Scroll (ve)":      true,
    "Sri Lankan Cinnamon Sugar": true,
}

func newDoughnutsBox(capacity int) *doughnutsBox {
    return &doughnutsBox{
        capacity:  capacity,
        doughnuts: make([]string, 0),
    }
}

func (b *doughnutsBox) pack(doughnuts []string) (int, error) {
    unrecognizedItems := make([]string, 0)
    var err error

    if len(doughnuts) > b.capacity {
        return 0, fmt.Errorf("failed to put %d doughnuts in the box, it's only has %d doughnuts capacity", len(doughnuts), b.capacity)
    }

    for _, doughnut := range doughnuts {
        if _, found := knownDoughnutTypes[doughnut]; found {
            b.doughnuts = append(b.doughnuts, doughnut)
            continue
        }
        unrecognizedItems = append(unrecognizedItems, doughnut)
    }

    if len(unrecognizedItems) > 0 {
        err = fmt.Errorf("the following items cannot be placed into the box: %v", unrecognizedItems)
    }
    return len(b.doughnuts), err
}

Now, after we familiarised ourself with the doughnut box implementation, let’s discuss how we can tests it.

Testing packing the doughnuts box with table-driven tests

Table-driven tests are the common way to write unit tests in Golang. You’ll find this style everywhere.

Table tests offer a condensed way to write test scenarios while keeping code repetition to a minimum. The syntax density is coming with the drawback of poor readability. The tests may feel elegant to write, but they are often hard to read and reason about.

The table-tests are shining in situations, where the intention is to test a large number of scenarios, with clear
input x produces output y expectations.

For our doughnut box example, we wrote a set of scenarios in the shape of anonymous struct testCases. Then we run all of them as subtests with t.Run method, inside a familiar for loop.

Implementation of doughnuts box table-driven tests

package doughnuts_box

import (
    "testing"

    "github.com/stretchr/testify/assert"
    "github.com/stretchr/testify/require"
)

func TestPackDoughnutsBoxTableTests(t *testing.T) {
    // Anonymous struct of test cases
    tests := []struct {
        name                           string
        boxCapacity                    int
        errorExpected                  bool
        errorMessage                   string
        items                          []string
        expectedNumOfDoughnutsInTheBox int
    }{
        {
            name:                           "Filling the box with tasty doughnuts",
            boxCapacity:                    4,
            errorExpected:                  false,
            errorMessage:                   "",
            items:                          []string{"Sri Lankan Cinnamon Sugar", "Matcha Tea", "Home Made Raspberry Jam", "Lime & Coconut (ve)"},
            expectedNumOfDoughnutsInTheBox: 4,
        },
        {
            name:                           "Attempt to fill the box with too many doughnuts",
            boxCapacity:                    4,
            errorExpected:                  true,
            errorMessage:                   "failed to put 5 doughnuts in the box, it's only has 4 doughnuts capacity",
            items:                          []string{"Sri Lankan Cinnamon Sugar", "Matcha Tea", "Home Made Raspberry Jam", "Lime & Coconut (ve)", "Lime & Coconut (ve)"},
            expectedNumOfDoughnutsInTheBox: 0,
        },
        {
            name:                           "Attempt to put a giant chocolate cookie into the box",
            boxCapacity:                    2,
            errorExpected:                  true,
            errorMessage:                   "the following items cannot be placed into the box: [Giant Chocolate Cookie]",
            items:                          []string{"Sri Lankan Cinnamon Sugar", "Giant Chocolate Cookie"},
            expectedNumOfDoughnutsInTheBox: 1,
        },
    }

    for _, tc := range tests {
        // each test case from  table above run as a subtest
        t.Run(tc.name, func(t *testing.T) {
            // Arrange
            box := newDoughnutsBox(tc.boxCapacity)

            // Act
            numOfDoughnutsInTheBox, err := box.pack(tc.items)

            // Assert
            if tc.errorExpected {
                require.Error(t, err)
                assert.Equal(t, tc.errorMessage, err.Error())
            }
            assert.Equal(t, tc.expectedNumOfDoughnutsInTheBox, numOfDoughnutsInTheBox)
        })
    }
}

We looked at the "happy path" test case and two test cases for errors we expect to be common - trying to put too many doughnuts into a box and an attempt to put something that isn't doughnut into the box.

Next, we'll look at how we can re-write the same tests in different style.

Testing packing the doughnuts box with individual subtests

Writing tests scenarios as an individual subtests is less common in Golang. This fact is regretful, in my opinion. But still there are enough of examples of this syntax.

Individual subtests syntax, unlike table tests, favours readability overall “code dryness”. The tests may look more repetitive, but each individual subtest represents an individual “story”. As such, it is easier to follow behaviour-driven testing principles with individual subtests than with table-driven tests.

In our small example, all arrangements are made within the individual subtests. In more complex examples, the state shared between subtests can be initialised in the body of the parent test. And repetitive setup/teardown can be extracted into helper functions.

Implementation of Donuts box test as individual subtests

package doughnuts_box

import (
    "testing"

    "github.com/stretchr/testify/assert"
    "github.com/stretchr/testify/require"
)

func TestPackDoughnutsBoxSubtests(t *testing.T) {
    t.Run("It fills the box with tasty doughnuts", func(t *testing.T) {
        // Arrange
        items := []string{"Sri Lankan Cinnamon Sugar", "Matcha Tea", "Home Made Raspberry Jam", "Lime & Coconut (ve)"}
        box := newDoughnutsBox(4)

        // Act
        numOfDoughnutsInTheBox, err := box.pack(items)

        // Assert
        require.NoError(t, err)
        assert.Equal(t, numOfDoughnutsInTheBox, 4)
    })
    t.Run("It fails to fill the box with too many doughnuts", func(t *testing.T) {
        // Arrange
        items := []string{"Sri Lankan Cinnamon Sugar", "Matcha Tea", "Home Made Raspberry Jam", "Lime & Coconut (ve)", "Lime & Coconut (ve)"}
        box := newDoughnutsBox(4)

        // Act
        numOfDoughnutsInTheBox, err := box.pack(items)

        // Assert
        require.Error(t, err)
        assert.Equal(t, "failed to put 5 doughnuts in the box, it's only has 4 doughnuts capacity", err.Error())
        assert.Equal(t, 0, numOfDoughnutsInTheBox)
    })
    t.Run("It fails to put a giant chocolate cookie into the box", func(t *testing.T) {
        // Arrange
        items := []string{"Sri Lankan Cinnamon Sugar", "Giant Chocolate Cookie"}
        box := newDoughnutsBox(4)

        // Act
        numOfDoughnutsInTheBox, err := box.pack(items)

        // Assert
        require.Error(t, err)
        assert.Equal(t, "the following items cannot be placed into the box: [Giant Chocolate Cookie]", err.Error())
        assert.Equal(t, 1, numOfDoughnutsInTheBox)
    })
}

We wrote the same three test cases - happy path and two common error scenarios as individual sub-tests. In our example, they even took approximately the same number of code lines. 58 lines for individual subtests, comparing to 63 lines of table-driven tests example.

Conclusions

Now, when examples for two styles for unit tests are presented, it is time to decide which one to use and when.

As an engineer, you should exercise your better judgement on how to write unit tests and what syntax suits best. You can use the following little diagram to help you to decide, which syntax to use.

I hope the diagram helps. If you have a strong opinion for one syntax over another or have your own way of writing Golang unit tests, please share in the comments!