"Test-drive" feels like a bit of a misnomer here. I was expecting more around performance and efficiency of sorting algorithms, but this article is mainly around how to build a test harness in Go.

I think "test-drive" here is supposed to mean do test-driven development.

A TDD satire ?

from:

"...let’s only add a new code into our implementation if we have a test scenario that would justify its existence!"

to:

"Now let’s implement some sorting algorithm here. For now, let’s use the the algorithm called Bubble Sort."

to:

"Since the go standard library is more efficient, let’s change our implementation to use that instead"

the author has a previous post praising TDD https://alabeduarte.com/tdd/, so I see no reason to believe it is satire: which is VERY confusing.

There is some good advice in this post. When something is broken, dont fix it until you have a test that demonstrates the issue.

What was the issue that required the pasting of bubble sort code?

100k elements in 14 seconds?

What do you mean "what was the issue that required the pasting of bubble sort code"? Are you responding to my comment?