Forem: Xuanyu Wang

Unmasking Hidden Test Pitfalls in Go: Avoiding False Positives

Xuanyu Wang — Wed, 25 Dec 2024 23:11:11 +0000

The nightmare in testing would be false positive. “Every thing is passing! Amazing!” until at an unknown time in the future all the mines explode together and blow your team to hell.

There are many reasons that tests could fail silently.

Today, I’m going to talk about one very basic reason: don’t know which are tests.

Why you don’t know which are tests?

Most people join a Go project half-way. Most people learn a language by using it in a real life.

Therefore, when someone had set up the project with a test framework like testify, you would most likely think methods like the following are tests.

func (suite *ExampleTestSuite) TestExample() {
    suite.Equal(5, suite.VariableThatShouldStartAtFive)
}

You then add another method like TestAnotherCase and find it works. You think you’re crystal clear about what are tests.

Test has different meanings in different frameworks

A “test” you’re talking may not be the same test a Go package is talking.

From the built in testing package, a test is any function of the form

func TestXxx(*testing.T)

Of course, since the built-in testing package has limited features, most projects are using testify/suite or other similar third-party package as their test framework. What is a test from the testify/suite's point of view?

add any methods that start with "Test" to add tests

See, we have two different definitions of a test.

The trouble starts when using a third-party testing tool

When using some tools like mockery, you’ll read the following

you won't have to worry about forgetting the AssertExpectations method call anymore … The AssertExpectations method is registered to be called at the end of the tests

Great! “So I only need to create a mock and the package will notify me when expected behaviors happen”.

That’s where the trap is.

When mockery says at the end of the tests, it actually means the definition from testing , not the definition from testify/suite.

So when you have the following code, you’ll see both TestA and TestB pass even they should both fail because the mock setup in TestA is used in TestB.

package mockandsubtest

import (
    "fmt"
    "testing"

    "github.com/stretchr/testify/suite"
)

// Prod code
type ExternalService interface {
    Work()
}

type Server struct {
    externalService ExternalService
}

func NewServer(externalService ExternalService) *Server {
    return &Server{
        externalService: externalService,
    }
}

// Test code
type ServerSuite struct {
    suite.Suite
    ExternalService *MockExternalService
    Server
}

func TestServerSuite(t *testing.T) {
    suite.Run(t, &ServerSuite{})
}

// Run before all test cases
func (s *ServerSuite) SetupSuite() {
    s.ExternalService = NewMockExternalService(s.T())
    s.Server = Server{externalService: s.ExternalService}
}

// In this test, Work is set up to be called once but not called
func (s *ServerSuite) TestA() {
    fmt.Println("TestA is running")
    s.ExternalService.EXPECT().Work().Times(1)
}

// In this test, Work is called once unexpectedly
func (s *ServerSuite) TestB() {
    fmt.Println("TestB is running")
    s.Server.externalService.Work()
}

The result of running the above code is

TestA is running
TestB is running
PASS

Explanation

It turns out only TestServerSuite is considered as a test from testing and mockery's point of view. That’s why the AssertExpectations is called at the end of TestServerSuite , even though TestA and TestB are internally executed by testify/suite.

From mockery's point of view, s.ExternalService is expected to be called once and actually called once in the lifecycle of TestServerSuite. So the expectation is fulfilled.

How to mitigate?

There are two ways to bridge the gap between testify/suite and testing.

The first way is creating a new mock before each test method like the following.

func (s *ServerSuite) SetupTest() {
    s.ExternalService = NewMockExternalService(s.T())
}

Sometimes, it’s not practical in your project due to many reasons like setting up a server instance for each test case is too expensive. Then you can try the other direction, which is manually asserting after each test.

The second one is adding a call of AssertExpectations at the end of each test method. For example, call AssertExpectations in TearDownTest , which is executed after each test method.

func (s *ServerSuite) TearDownTest() {
    s.ExternalService.AssertExpectations(s.T())
}

Pagination condition for multiple columns

Xuanyu Wang — Tue, 21 May 2024 01:55:03 +0000

There are many ways to do pagination in production.

In this article, I'll explore an efficient method for pagination in production environments: fetching records up to the page size using conditions based on the last record's values.

This approach ensures that records on subsequent pages are consistently ordered, even if the database is updated between page views.

Why not `OFFSET`?

It’s not efficient

According to the documentation of Postgres

OFFSET says to skip that many rows before beginning to return rows.

and

The rows skipped by an OFFSET clause still have to be computed inside the server; therefore a large OFFSET might be inefficient.

Therefore, when querying a large volume of data, using OFFSET may degrade the performance especially when querying for the last few pages.

Customers could be confused

Unless the data is fixed during the session of browsing pages, using OFFSET can return correct but confusing data because the records could be updated between pages.

For example, after displaying the first page of 10 records and before displaying the second page, new records could be inserted into the database. Accidentally, the records are sorted in the first place. When the second page is displayed, a user will see the first record on the second page as the 10th record displayed on the first page because it’s squeezed out of the first page.

What’s the `WHERE` clause?

The core is defining the WHERE clause.

It’s easy to write the WHERE clauses when ordered by one column. It becomes tricky when ordered by multiple columns. Let’s start from order by one column, then two columns, and finally expand to any number of columns.

Case study: order by one column

Let’s say there is a table like the following

CREATE TABLE IF NOT EXISTS examples (
    B TIMESTAMP NULL,
    CONSTRAINT unique_b UNIQUE (B)
);

Column B is nullable and contains only unique values.

Let’s say the column B's value of the last record of the last page is b. Then the records sorted after b could be categorized into the following cases:

when b is NULL and column B is sorted with NULLS LAST. In this case, b is already the last value of column B and there is no value after it. We can use condition B IS NULL AND B IS NOT NULL to represent.
when b is NULL and column B is sorted with NULLS FIRST. In this case, values after b should be non-null. The condition is B IS NOT NULL
when b is not NULL and column B is sorted with NULLS LAST. The values after b could be NULL or non-null. The condition is B > b OR B IS NULL (when column B is sorted in ascending order) or B < b OR B IS NULL (when column B is sorted in descending order)
when b is not NULL and column B is sorted with NULLS FIRST. The values after b can only be non-null. The condition is B > b or B < b depending on the sorting direction.

Case study: order by two columns

Let’s say there is a table like the following

CREATE TABLE IF NOT EXISTS examples (
    A INT NULL,
    B TIMESTAMP NULL,
    CONSTRAINT unique_ab UNIQUE (A, B)
);

Both column A and B are nullable and their value combinations are unique.

Assuming in the last record of the last page, column A's value is a and column B's value is b. The query will sort A first and sort B second.

The records after the first page should fall in one of the following cases:

their column A’s value is equal to a but their column B's value is sorted after b
their column A's value is sorted after a, regardless of their column B's value.

Expand to multiple columns

After looking at the base case (sorting by one column) and how two columns are sorted, we can easily induce the following conclusion:

When a query is sorted by multiple columns column 1, column 2, ..., column N where N >= 1 , all records (whose values are a1, a2, ..., aN) after a record whose values are v1, v2, ..., vN should meet one of the following conditions:

a1 is sorted after v1 , regardless what values a2, ... aN are
a1 equals to v1, and a2, ..., aN should be sorted after v2, ..., vN.

Example data

Let’s say the page size is 5. The result is sorted by two columns A in ascending order and B in descending order, which is ORDER BY A ASC NULLS LAST, B DESC NULLS FIRST. There is no duplicate combination of A and B's value (which is UNIQUE (A, B))

There are different kinds of records that could appear on the 2nd page:

The values of the 5th row are not null. The 6th row could be one of the following cases

row A B

5 20 2020-02-01

6 20 2020-01-31

row A B

5 20 2020-02-01

6 21 NULL

row A B

5 20 2020-02-01

6 NULL 2020-01-31

row A B

5 20 2020-02-01

6 NULL NULL
when only the 5th row’s B value is NULL, then the 6th row could be

row A B

5 20 NULL

6 20 2020-01-31

row A B

5 20 NULL

6 21 NULL
when only the A value of the 5th row is NULL, then the 6th row could be

row A B

5 NULL 2020-02-01

6 NULL 2020-01-31
when values of the 5th row are all NULL, then the 6th row could be

row A B

5 NULL NULL

6 NULL 2020-01-31

row	A	B
5	20	2020-02-01
6	20	2020-01-31

row	A	B
5	20	2020-02-01
6	21	NULL

row	A	B
5	20	2020-02-01
6	NULL	2020-01-31

row	A	B
5	20	2020-02-01
6	NULL	NULL

row	A	B
5	20	NULL
6	20	2020-01-31

row	A	B
5	20	NULL
6	21	NULL

row	A	B
5	NULL	2020-02-01
6	NULL	2020-01-31

row	A	B
5	NULL	NULL
6	NULL	2020-01-31

Algorithm code in GO

The full code is at https://github.com/xuanyuwang/go-db-examples/blob/main/pagination/pagination.go

I’ll break the full code later.

package pagination

import (
    "fmt"
)

const (
    Asc   = "ASC"
    Desc  = "DESC"
    First = "FIRST"
    Last  = "LAST"
)

type OrderByColumn struct {
    SortExpresssion string
    Direction       string // ASC or DESC
    NullOption      string // FIRST or LAST
}

type Condition struct {
    SQL    string        // like "A = ? AND B > ?"
    Values []interface{} // like []interface{}{20, "2020-01-01"}
}

func (c *Condition) mergeValues(values []interface{}) {
    if len(values) > 0 {
        c.Values = append(c.Values, values...)
    }
}

func NextPage(
    columns []OrderByColumn, // the definition of ORDER BY columns
    values []interface{}, // the values of the last row of the last page
) Condition {
    column := columns[0]
    // The value of column.SortExpression in the last row of the last page
    prevValue := values[0]

    sign := "<"
    if column.Direction == Asc {
        sign = ">"
    }

    if len(columns) == 1 {
        condition := Condition{SQL: "", Values: make([]interface{}, 0, len(columns))}

        switch {
        case prevValue == nil && column.NullOption == Last:
            // No value after NULL
            condition.SQL = fmt.Sprintf("(%s IS NOT NULL AND %s IS NULL)", column.SortExpresssion, column.SortExpresssion)
        case prevValue == nil && column.NullOption == First:
            condition.SQL = fmt.Sprintf("(%s IS NOT NULL)", column.SortExpresssion)
        case prevValue != nil && column.NullOption == Last:
            // the next row could be NULL
            condition.SQL = fmt.Sprintf("((%s %s ?) OR (%s IS NULL))", column.SortExpresssion, sign, column.SortExpresssion)
            condition.Values = []interface{}{prevValue}
        case prevValue != nil && column.NullOption == First:
            condition.SQL = fmt.Sprintf("(%s %s ?)", column.SortExpresssion, sign)
            condition.Values = []interface{}{prevValue}
        }
        return condition
    } else {
        condition := NextPage(columns[1:], values[1:])
        var newCondition Condition
        switch {
        case prevValue == nil && column.NullOption == Last:
            newCondition.SQL = fmt.Sprintf("((%s IS NULL) AND %s)", column.SortExpresssion, condition.SQL)
            newCondition.mergeValues(condition.Values)
        case prevValue == nil && column.NullOption == First:
            newCondition.SQL = fmt.Sprintf("((%s IS NOT NULL) OR ((%s IS NULL) AND %s))", column.SortExpresssion, column.SortExpresssion, condition.SQL)
            newCondition.mergeValues(condition.Values)
        case prevValue != nil && column.NullOption == Last:
            // the next row could be NULL
            newCondition.SQL = fmt.Sprintf(
                "(((%s %s ?) OR (%s IS NULL)) OR ((%s = ?) AND %s))",
                column.SortExpresssion, sign, column.SortExpresssion, column.SortExpresssion, condition.SQL,
            )
            newCondition.mergeValues([]interface{}{prevValue, prevValue})
            newCondition.mergeValues(condition.Values)
        case prevValue != nil && column.NullOption == First:
            newCondition.SQL = fmt.Sprintf("(%s %s ?) OR ((%s = ?) AND %s)", column.SortExpresssion, sign, column.SortExpresssion, condition.SQL)
            newCondition.mergeValues([]interface{}{prevValue, prevValue})
            newCondition.mergeValues(condition.Values)
        }
        return newCondition
    }
}

Let me break down the code into sections. The following code sections are not exactly the same as the full code for readability consideration.

Define `ORDER BY` column

At first, we need to understand what defines an ORDER BY column.

According to the doc of Postgresql, an ORDER BY column defined by

a sort expression. “The sort expression(s) can be any expression that would be valid in the query's select list”
a sort direction, which is either ASC or DESC
a null position, which is NULLS FIRST or NULLS LAST

It’s straightforward to create a struct for order by columns like the following

// Note the Direction field and NullOption would better be enum
type OrderByColumn struct {
    SortExpresssion string
    Direction       string // ASC or DESC
    NullOption      string // FIRST or LAST
}

const (
    Asc   = "ASC"
    Desc  = "DESC"
    First = "FIRST"
    Last  = "LAST"
)

Generate the condition for the base case which is sorting on one column

Let’s first define the condition struct

type Condition struct {
    SQL    string        // like "A = ? AND B > ?"
    Values []interface{} // like []interface{}{20, "2020-01-01"}
}

func (c *Condition) mergeValues(values []interface{}) {
    if len(values) > 0 {
        c.Values = append(c.Values, values...)
    }
}

Then the condition for sorting one one column is

    condition := Condition{SQL: "", Values: make([]interface{}, 0, len(columns))}

    // `column` is of type OrderByColumn.
    // `prevValue` is the value of `column` in the last record of the last page
    switch {
    case prevValue == nil && column.NullOption == Last:
        // No value after NULL
        condition.SQL = fmt.Sprintf("(%s IS NOT NULL)", column.SortExpresssion)
    case prevValue == nil && column.NullOption == First:
        condition.SQL = fmt.Sprintf("(%s IS NOT NULL)", column.SortExpresssion)
    case prevValue != nil && column.NullOption == Last:
        // the next row could be NULL
        condition.SQL = fmt.Sprintf("((%s %s ?) OR (%s IS NULL))", column.SortExpresssion, sign, column.SortExpresssion)
        condition.Values = []interface{}{prevValue}
    case prevValue != nil && column.NullOption == First:
        condition.SQL = fmt.Sprintf("(%s %s ?)", column.SortExpresssion, sign)
        condition.Values = []interface{}{prevValue}
    }

    return condition

Once we have the condition for the columns except the first column, then we can define the condition for all columns by

        condition := NextPage(columns[1:], values[1:])
        var newCondition Condition
        switch {
        case prevValue == nil && column.NullOption == Last:
            newCondition.SQL = fmt.Sprintf("((%s IS NULL) AND %s)", column.SortExpresssion, condition.SQL)
            newCondition.mergeValues(condition.Values)
        case prevValue == nil && column.NullOption == First:
            newCondition.SQL = fmt.Sprintf("((%s IS NOT NULL) OR ((%s IS NULL) AND %s))", column.SortExpresssion, column.SortExpresssion, condition.SQL)
            newCondition.mergeValues(condition.Values)
        case prevValue != nil && column.NullOption == Last:
            // the next row could be NULL
            newCondition.SQL = fmt.Sprintf(
                "(((%s %s ?) OR (%s IS NULL)) OR ((%s = ?) AND %s))",
                column.SortExpresssion, sign, column.SortExpresssion, column.SortExpresssion, condition.SQL,
            )
            newCondition.mergeValues([]interface{}{prevValue, prevValue})
            newCondition.mergeValues(condition.Values)
        case prevValue != nil && column.NullOption == First:
            newCondition.SQL = fmt.Sprintf("(%s %s ?) OR ((%s = ?) AND %s)", column.SortExpresssion, sign, column.SortExpresssion, condition.SQL)
            newCondition.mergeValues([]interface{}{prevValue, prevValue})
            newCondition.mergeValues(condition.Values)
        }
        return newCondition

Example usage

In the unit tests at https://github.com/xuanyuwang/go-db-examples/blob/main/pagination/pagination_test.go, you can find how the NextPage is used.

Test in Go: trick of Cleanup

Xuanyu Wang — Sun, 18 Feb 2024 19:34:12 +0000

My team is using testify as the testing framework for Go. We noticed that many methods provided by testify/suite can be easily achieved by the built-in testing package. For example, using Cleanup can do the same of AfterTest provided by testify/suite. It makes me wondering if we can just use Cleanup to replace as much methods from third-party packages as possible.

TL;DR

Cleanup can replace methods that are not relevant to subtests, which are AfterTest, TearDownAllSuite and TearDownTestSuite.

Cleanup can’t replace TearDownSubTest because there is a risk that a subtest pollute its parent test.

The experiment

I use a global variable externalResource as the external resource. It’s value is 1.

When preparing a subtest at SetupSubTest, externalResource is changed to 2. At the same time, a cleanup function is registered to restore externalResource to 1.

I expect that externalResource is set to 2 before the subtest and restored to 1 once the subtest is finished. So, from the point of parent test, externalResource is always 1. From the point of subtest, externalResource is always 2.

The code is

var externalResource = 1

type TestUnexpectedCleanupOrder struct {
    suite.Suite
}

func (s *TestUnexpectedCleanupOrder) TearDownTest() {
    fmt.Println("TearDownTest")
}

func (s *TestUnexpectedCleanupOrder) SetupSubTest() {
    externalResource = 2
    fmt.Printf("SetupSubTest. The externalResoure is: %d\n", externalResource)
    s.T().Cleanup(func() {
        externalResource = 1
        fmt.Printf("SetupSubTest. The externalResoure is: %d\n", externalResource)
    })
}

// Test case
func (s *TestUnexpectedCleanupOrder) TestCaseA() {
    fmt.Printf("Start TestCase A. The externalResoure is: %d\n", externalResource)

    s.Run("Sub-TestCase A", func() {
        fmt.Printf("Finish Sub-TestCase A. The externalResoure is: %d\n", externalResource)
    })
    fmt.Printf("Finish TestCase A. The externalResource is: %d\n", externalResource)
}

The result

The output of the above code is (with line number)

1 Start TestCase A. The externalResoure is: 1
2   SetupSubTest. The externalResoure is: 2
3   Finish Sub-TestCase A. The externalResoure is: 2
4 Back to TestCase A. The externalResource is: 2
5 TearDownTest
6   Cleanup subTest. The externalResoure is: 1

Notice line 4 and line 6. The externalResource is still 2 when the subtest is finished and the parent test is resuming! externalResource is not cleaned until the parent test is finished.

According to the documentation of Cleanup:

Cleanup registers a function to be called when the test (or subtest) and all its subtests complete. Cleanup functions will be called in last added, first called order.

It only guarantee that a registered function is called after something.

It does NOT guarantee when a registered function is called before something.

The solution

If we add a TearDownSubTest to reset externalResource, then its value is cleaned as we need

func (s *TestUnexpectedCleanupOrder) TearDownSubTest() {
    externalResource = 1
    fmt.Printf("\tTeardown subTest. The externalResoure is: %d\n", externalResource)
}

Start TestCase A. The externalResoure is: 1
    SetupSubTest. The externalResoure is: 2
    Finish Sub-TestCase A. The externalResoure is: 2
    Teardown subTest. The externalResoure is: 1
Back to TestCase A. The externalResource is: 1
TearDownTest
    Cleanup subTest. The externalResoure is: 1

Summary

We can use Cleanup to clean up resources for normal tests. However, we need to use TearDownSubTest to clean the resource held by subtests.

The source code

https://github.com/xuanyuwang/testify-examples/tree/main/unexpected-cleanup-order

Test in Go: the order of Cleanup is not what you think

Xuanyu Wang — Mon, 12 Feb 2024 03:04:47 +0000

The framework [testify](https://github.com/stretchr/testify/tree/v1.8.4) might be the most popular. Surprisingly, I find the documentation is not clear enough to answer my questions and I can't find answers anywhere. Therefore, I have to write experiments to verify my guesses.

One of my questions is: when will the registered Cleanup functions run?

The summary of my experiment shows that the order of Cleanup functions is running as we normally expected except for those from subtests. The exception could lead severe problems.

The experiment

The idea is simple: register Cleanup functions from all setup/teardown methods and use the log to infer the execution order.

Let's have a peek at the result first.

We can see that the Cleanup functions registered at TearDownSubTest and SetupSubTest are called after the subtests are finished. However, it's NOT guaranteed that they will be called immediately after a subtest is finished.

There are two scenarios:

For nested subtests, the Cleanup functions registered at TearDownSubTest and SetupSubTest are called once their parents are finished but not cleaned.
For direct subtests whose parents are NOT subtests, their Cleanup functions registered at TearDownSubTest and SetupSubTest are called once the parents' AfterTest and TearDownTest are finished.

The impact is:

Nested subtests could pollute each other because some Cleanup functions are running after all sibling subtests.
Children subtest can even pollute their parents.

The source code can be found here: https://github.com/xuanyuwang/testify-examples/blob/main/cleanup-order/cleanup_order_test.go

package cleanuporder_test

import (
    "fmt"
    "testing"

    "github.com/stretchr/testify/suite"
)

var tearDownSubTest []string

type TestCleanupOrder struct {
    suite.Suite
}

func (s *TestCleanupOrder) SetupSuite() {
    fmt.Println("Run Interface SetupAllSuite: SetupSuite")
    s.T().Cleanup(func() {
        fmt.Println("Cleanup Interface SetupAllSuite: SetupSuite")
    })
}

func (s *TestCleanupOrder) SetupTest() {
    fmt.Println("Run Interface SetupTestSuite: SetupTest")
    s.T().Cleanup(func() {
        fmt.Println("Cleanup Interface SetupTestSuite: SetupTest")
    })
}

func (s *TestCleanupOrder) TeatDownSuite() {
    fmt.Println("Run Interface TearDownAllSuite: TearDownSuite")
    s.T().Cleanup(func() {
        fmt.Println("Cleanup Interface TearDownAllSuite: TearDownSuite")
    })
}

func (s *TestCleanupOrder) TearDownTest() {
    fmt.Println("Run Interface TearDownTestSuite: TearDownTest")
    s.T().Cleanup(func() {
        fmt.Println("Cleanup Interface TearDownTestSuite: TearDownTest")
    })
}

func (s *TestCleanupOrder) BeforeTest(suiteName, testName string) {
    fmt.Printf("Run Interface BeforeTest: BeforeTest for suite %s - test %s\n", suiteName, testName)
    s.T().Cleanup(func() {
        fmt.Printf("Cleanup Interface BeforeTest: BeforeTest for suite %s - test %s\n", suiteName, testName)
    })
}

func (s *TestCleanupOrder) AfterTest(suiteName, testName string) {
    fmt.Printf("Run Interface AfterTest: AfterTest for suite %s - test %s\n", suiteName, testName)
    s.T().Cleanup(func() {
        fmt.Printf("Cleanup Interface AfterTest: AfterTest for suite %s - test %s\n", suiteName, testName)
    })
}

func (s *TestCleanupOrder) HandleStats(suiteName string, stats *suite.SuiteInformation) {
    fmt.Printf("Run Interface WithStats: HandleStats for suite %s\n", suiteName)
    s.T().Cleanup(func() {
        fmt.Printf("Cleanup Interface WithStats: HandleStats for suite %s\n", suiteName)
    })
}

func (s *TestCleanupOrder) SetupSubTest() {
    fmt.Println("Run Interface SetupSubTest: SetupSubTest")
    s.T().Cleanup(func() {
        fmt.Println("Cleanup Interface SetupSubTest: SetupSubTest")
    })
}

func (s *TestCleanupOrder) TearDownSubTest() {
    fmt.Println("Run Interface TearDownSubTest: TearDownSubTest")
    s.T().Cleanup(func() {
        fmt.Println("Cleanup Interface TearDownSubTest: TearDownSubTest")
        fmt.Printf("\tTear down sub test %v\n", tearDownSubTest)
    })
}

// Test case
func (s *TestCleanupOrder) TestCaseA() {
    fmt.Println("Run TestCase A")
    s.T().Cleanup(func() {
        fmt.Println("Cleanup TestCase A")
    })

    s.Run("Sub-TestCase A", func() {
        fmt.Println("Run Sub-TestCase A")
        s.T().Cleanup(func() {
            fmt.Println("Cleanup Sub-TestCase A")
        })
        tearDownSubTest = append(tearDownSubTest, "Sub-TestCase A")

        s.Run("Sub-Sub-TestCase A", func() {
            s.T().Cleanup(func() {
                fmt.Println("Cleanup Sub-Sub-TestCase A")
            })
            fmt.Println("Run Sub-Sub-TestCase A")
            tearDownSubTest = append(tearDownSubTest, "Sub-Sub-TestCase A")
            fmt.Println("Finish Sub-Sub-TestCase A")
        })
        s.Run("Sub-Sub-TestCase B", func() {
            s.T().Cleanup(func() {
                fmt.Println("Cleanup Sub-Sub-TestCase B")
            })
            fmt.Println("Run Sub-Sub-TestCase B")
            tearDownSubTest = append(tearDownSubTest, "Sub-Sub-TestCase B")
            fmt.Println("Finish Sub-Sub-TestCase B")
        })

        fmt.Println("Finish Sub-TestCase A")
    })
    fmt.Println("Finish TestCase A")
}

// Entry point of the whole test suite
func TestCleanupOrderSuite(t *testing.T) {
    suite.Run(t, &TestCleanupOrder{})
}

MVP is not Minimum Viable Product

Xuanyu Wang — Sun, 31 Dec 2023 19:58:11 +0000

MVP is the acronym for “Minimum Viable Product.” That’s correct.

However, MVP does not mean minimum viable products. It’s a very common mistake that startups make.

Here's why.

What does MVP mean?

The idea is that we need

A version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. — , Eric Ries

That’s a golden idea, but the use of the word "product" can easily confuse people. If your goal is to make an electric car, you may want to build a smaller and simpler version and call it a product. However, that’s incorrect.

According to the definition, an MVP is something that can maximize the value of

\frac{validated\ learning\ about\ customers}{effort}

It could be anything. Think out of the box.

What could a MVP?

Does such a thing have to be a product in the form you’re thinking? Not really.

Let’s say there is a game that has been pre-ordered one million times and raised 100 million because of that. Would you think the propagation of that game has provided validated learning about customers? Does it matter that there could be just a video without a single line of code? No, it doesn’t. The idea of the game has been fully proven by customers’ real money. So, this is a successful MVP because with the effort of making a video (which takes a few weeks), they gathered feedback from customers.

What else could be a MVP

Surveys. You can learn what features customers like or dislike, how much money they’re willing to pay for a specific feature.

Videos. Post a video on YouTube and see if people are excited about it. Tweets and posts on different forums are the same idea.

Crowdfunding. If you can convince others about your production idea, you probably should pursue it.

VC. Venture Capital firms are the best people to evaluate your production idea. They can’t tell you what’s a good product, but they usually can point out what are bad ones.

Basically, it could be anything. A rule of thumb is pushing back building a real product as much as possible. The easy mistake is jumping directly into doing a real thing. This is especially common for people who are engineers.

Original Post

Book Recommendation for Developers: Hello, Startup

Xuanyu Wang — Sat, 30 Dec 2023 20:52:20 +0000

Every time I’m looking for new opportunities, I always find myself in a dilemma of choosing a big, established company or a startup.

I want to hear the insights of big corporations and startups.

I searched on the internet but only found some short articles or videos that briefly discussed the pros and cons of them and the author’s personal experience.

They are great content indeed. However, they only give me stories instead of insights. I know many versions of “someone with that background joined a big corporation because of y and later he/she found z”. They don’t actually help me to make a decision. I need to know the fundamental principles or the intrinsics of startups or big corporations.

This book gives me that, and beyond.

Its value for a university student

You’re going to trade 4 years of the best part of your life and a significant amount of tuition fee for something.

The problem is: what the “something” is? It would be ridiculous that you don’t even know what you’re buying. Unfortunately, that’s true for most of the people.

This book tells you what is available in the shop and especially and carefully explains the startup category.

I agree that big and established companies would be better for new graduates. I still highly recommend this book for two particular reasons for new graduates.

First, “Invert, always invert”, said Charlie Munger. As startups are the opposite of big companies, you can’t fully understand the value and uniqueness of big companies if you don’t know startups well.

Second, sometimes, you just don’t have that much choice. Or you’re exactly the type of person who should go directly into a startup or even found your own startup. Who knows?

Its value for a junior developer

My first job was in a big company. After a few months of working there, I couldn’t help but think that I may repeat those mediocre daily routines for my whole life. That idea terrified me to my bones! I wanted to commit myself to making a difference. But I didn’t know what difference I could make and what I should make.

I wish I could have had this book at that time. Then I would know there is another different world I can fly to (of course, evaluate your own situation before making any decision. Don’t escape from your own problems) and how should I prepare for picking and applying to a startup.

What if your first job is in a startup? Then this book is just for you!

Have you wondered if your company is doing right on something? Have you been stressed out but don’t know if it’s because your resilience level is low or simply because the work environment is toxic? Do you want to make a change to your company but don’t know where to start?

This book can answer all of the questions that are related to a developer. After reading it, you would know what’s the benchmark of startups and you can go from there to do whatever you want.

Or you want to start a company

Starting a company is nothing the same as working for a startup. This book covers the technical aspects like

what kind of working culture your company should have?
what kind of tech stack there should be?
what is important to your codebases, and what could be trade-offs?
how to hire talents for your company?

As a co-founder, your understanding and attitude of engineering would impact many people who build products for you. Sometimes, that’s exactly why a company succeeds or fails.

My review

After working for many companies, including big companies and startups, I find everything this book articulates exactly what I feel in a clear, fun, and straightforward way.

I would recommend it to the 10-years-younger myself. I’m a bit late now to read it though I still get a lot of nutrition from it and I believe it can help to boost my career to a new level.

Resource

The official site of the book: https://www.hello-startup.net

Forem: Xuanyu Wang

Unmasking Hidden Test Pitfalls in Go: Avoiding False Positives

Why you don’t know which are tests?

Test has different meanings in different frameworks

The trouble starts when using a third-party testing tool

Explanation

How to mitigate?

Pagination condition for multiple columns

Why not OFFSET?

It’s not efficient

Customers could be confused

What’s the WHERE clause?

Case study: order by one column

Case study: order by two columns

Expand to multiple columns

Example data

Algorithm code in GO

Define ORDER BY column

Generate the condition for the base case which is sorting on one column

Example usage

Test in Go: trick of Cleanup

TL;DR

The experiment

The result

The solution

Summary

The source code

Test in Go: the order of Cleanup is not what you think

The experiment

MVP is not Minimum Viable Product

What does MVP mean?

What could a MVP?

What else could be a MVP

Further reading

Original Post

Book Recommendation for Developers: Hello, Startup

Its value for a university student

Its value for a junior developer

Or you want to start a company

My review

Resource

Why not `OFFSET`?

What’s the `WHERE` clause?

Define `ORDER BY` column