DEV Community: Gustavo Lopes

Go tests - How to verify if something was called?

Gustavo Lopes — Fri, 01 Apr 2022 23:17:30 +0000

Hello, gophers

I was talking to a friend and remembering some challenges we faced when we start our journey in Golang. For context, we both came from a NodeJS background, a land where there are some tests frameworks like the famous Jest which provide methods like .toHaveBeenCalled(), toHaveBeenCalledTimes(number) and .toHaveBeenCalledWith(...), etc.

On other hand, at the Go world, the native testing package suits well for (almost) all scenarios of unit tests, but it does not provide a clear way to do things like verifying if something was called and the plot twist is that it doesn't need to. As Go provide great idiomatic ways to perform thing like this, we don't need to use any framework.

Okay, but how to verify something was called in "Go idiomatic way"?

The answer is simple: using interfaces and dependency inversion!

So, let's talk a bit about dependency inversion

As a good practice of encapsulation, it's recommended that we use interfaces to abstract types whenever is possible in our code. For example, suppose we want to define structs that represent dogs of specific breeds, like these:



package dogs

type DogLhasa struct {
    Name string
} 

func (d *DogLhasa) Bark() string {
    return "woof-AUAU"
}

type DogRotweiler struct {
    Name string
}

func (d *DogRotweiler) Bark() string {
    return "woof-woof-ARHHHHHGG"
}

And suppose that we have a function that calls the Bark() method of a dog passed as an argument. The question is how to define this function? Without using interfaces, we have to do something weird like this:



func MakeDogLhasaBark(dog DogLhasa) string {
    return dog.Bark()
}

func MakeDogRotweilerBark(dog DogRotweiler) string {
    return dog.Bark()
}

It's clear that this doesn't scale well, right? Imagine what a mess it would be if we have to write a function like this for every dog bread we want to add to our code.
To work around this, we must work with interfaces. We define an interface that defines what a dog should be, and every code that deals with dogs can relay up this interface.



type Dog interface {
    Bark() string
}

func MakeDogBark(dog Dog) string {
    return dog.Bark()
}

And now when we call MakeDogBark, we can pass whatever object of the type of some struct that implements the interface Dog.



func main() {
    dog := &DogLhasa{Name: "Rex"}
    MakeDogBark(dog)
}

A lot simpler, isn't it? This is called dependency inversion - instead of depending on some specific dog struct, our function MakeDogBark depends on the interface Dog that defines what a struct must implement to be a Dog. Thus, the MakeDogBark function can accept any object of any struct that implements the interface Dog. Check this visual representation of dependency inversion:

But how exactly this can help us to implement tests like the toHaveBeenCalled.* ones?

Let's write a unit test to the function MakeDogBark. In this test, we want to ensure that when MakeDogBark is called, the Bark method of dog passed as argument is called. To do this, we can create a "fake dog" struct that allows us to keep track of how many times the method Bark was called. Like this:



type fakeDog struct {
    numberOfBarks int
}

func (d *fakeDog) Bark() string {
    d.numberOfBarks++
    return "woof"
}

This way, we increase the variable numberOfBarks every time an object of type fakeDog barks. So, to test if the Bark method was called, we just have to check if the numberOfBarks is greater than zero.



func TestMakeDogBark(t *testing.T) {
    dog := &fakeDog{}

    MakeDogBark(dog)

    // fail if the dog didn't bark
    if dog.numberOfBarks == 0 {
        t.Errorf("Expected dog to bark once, but it barked %d times", dog.numberOfBarks)
    }
}

Similar heuristics can be used to achieve variations of toHaveBenCalled.* tests. For example:

toHaveBeenCalledWith



type fakeStruct struct {
    calledWith string
}

func (f *fakeStruct) SomeMethod(s string) {
    f.calledWith = s
}

func TestSomeMethod(t *testing.T) {
    f := &fakeStruct{}
    f.SomeMethod("hello")
    if f.calledWith != "hello" {
        t.Errorf("Expected SomeMethod to be called with 'hello', but was called with '%s'", f.calledWith)
    }
}

toHaveBeenCalledTimes



type fakeStruct struct {
    calledTimes int
}

func (f *fakeStruct) SomeMethod() {
    f.calledTimes++
}

func TestSomeMethod(t *testing.T) {
    f := &fakeStruct{}

    f.SomeMethod()
    f.SomeMethod()
    f.SomeMethod()

    if f.calledTimes != 3 {
        t.Errorf("Expected f.calledTimes to be 3, but it was %d", f.calledTimes)
    }
}

Pretty nice, right? It's amazing how much we can achieve with Golang just using native stuff, with no third-party framework or libraries.

Happy testing! 🧪

A pattern to solve Binary Tree problems with Golang

Gustavo Lopes — Thu, 17 Mar 2022 00:51:35 +0000

I was reviewing some binary tree concepts when YouTube recommended this amazing video from the Inside code channel. In a nutshell, this video shows how the simple recursive definition of a binary tree can be used to solve a lot of binary tree problems in code interviews. So, I decided to write this article, summarizing the idea and applying it to real-life solving some questions from LeetCode and GeeksForGeeks using Golang.

The simple recursive definition of a binary tree

As I pointed out before, the recursive definition of a binary tree is enough to turn us able to solve a huge amount of code interview questions. Thus, let's look at this definition.

The recursive definition of a binary tree accordingly with Stanford CS Education Library is:

"[...] a binary tree is either empty (represented by a null pointer) or is made of a single node, where the left and right pointers (recursive definition ahead) each point to a binary tree."

In other words, a binary tree is made by:

A root node
A left node pointing to a subtree or a NULL pointer
A right node pointing to a subtree or a NULL pointer

Where each "subtree" can be seen as binary trees (hence the recursive definition).

I tried to make a visualization of this in the figure below:

From a code perspective, we can write a BinaryTree data structure:

 type BinaryTree struct {
      Val int
      Left *BinaryTree
      Right *BinaryTree
 }

Okay, but how to use this to solve code interview problems? 🤔

A huge amount of code interview questions related to binary trees are to calculate some tree property or manipulate the tree in some specific way. Thus, we can approach these questions with the same logic of recursive definition of a binary tree, as shown below:

1. Calculate some property of a binary tree

1. Calculate the property for the root node
2. Recursively calculate the property for the tree at left
3. Recursively calculate the property for the tree at right
4. Merge those calculations and output the result

2. Manipulate a tree in some specific way

1. Manipulate the tree at left
2. Manipulate the tree at right
3. Attach root node to the manipulated right and left trees

It is yet a little abstract, right? So let's dive into some code questions to put this into practice.

Calculate maximum depth (or height) of a tree

LeetCode question
The tree depth is defined as the length from some source node to root node. Since on this question we are interested in the maximum depth, we want to calculate the depth from leaves to root node and select the maximum among them. This is exactly the definition of the height of a tree, which is the length of the longest path to a leaf node from the root node. We can rewrite this definition in the recursive form:

The height of a tree is 1 + maximum between the height of the left tree and the right tree.

Now, implement this is pretty straightforward:

func maxDepth(root *TreeNode) int {
    if root == nil {
        return 0
    }
    leftMaxDepth := float64(maxDepth(root.Left))
    rightMaxDepth := float64(maxDepth(root.Right))
    return 1 + int(math.Max(leftMaxDepth, rightMaxDepth))
}

Reverse a binary tree

LeetCode question
Reverse a binary tree is a manipulation on a tree where all the nodes which were previously at the left of the tree go to the right of the tree and all the nodes from the right go to the left. The image below (from LeetCode question) makes it clearly:

We also can approach this recursively:

1. reverse the tree on the left
2. reverse the tree on the right
3. swap the left and right trees

The Golang code is showed bellow:

func invertTree(root *TreeNode) *TreeNode {
    if root == nil {
        return nil
    }
    invertTree(root.Left)
    invertTree(root.Right)
    root.Left, root.Right = root.Right, root.Left
    return root
}

Get the maximum (or minimum) value in a tree

GeeksForGeeks question
The maximum value in a tree is simply the maximum between the value of the tree's root, the maximum of the left tree, and the maximum of the right tree. Once again, the recursive definition shows up.

import "math"

func maximumInTree(root *TreeNode) float64 {
    if root == nil {
        return math.Inf(-1)
    }
    maximumInLeft := maximumInTree(root.Left)
    maximumInRight := maximumInTree(root.Right)
    maximumInChildren := math.Max(maximumInLeft, maximumInRight)
    return math.Max(maximumInChildren, root.Val)
}

You got the idea, right? 💡

In summary, what I want say to you is that the recursive binary tree definition is a great start point when thinking about resolution of some problem related to binary trees. Of course it's not a silver bullet, since some questions may require different approaches like traversing iteratively by levels instead of recursively, but this is a subject for another post.

Hope it'll be useful for you!