TDD Practicality

Steven Kaufman — Thu, 22 Apr 2021 05:39:22 +0000

Background

As a young person getting into programming, it's hard not to notice the wildly varying cultural perspectives around the industry.
From just watching YouTube tutorials, I think I was completely oblivious to the very existence of unit testing for at least a full year after learning the fundamentals of Javascript.

Shortly after, however, I stumbled upon Robert C. Martin (Uncle Bob)'s talks on YouTube.
If you haven't already seen his six publicly available hour-and-a-half long talks, I highly recommend watching ALL of them.
I've personally rewatched and listened to them like podcasts in the car at least three times over.

Youtube: Clean Code - Uncle Bob

Uncle Bob and TDD

To summarize, he's one of the authors of the Agile Manifesto, a 50+ year software professional, and an extreme advocate for Test Driven Development.

This advocacy for TDD sets him apart from even some of the other people who worked on the Agile Manifesto (which was designed to be a great compromise between wildly different programming philosophies).

My Question

After playing around with TDD in personal projects, I can see its value, and I'm inclined to believe what Uncle Bob says. However, I want to be careful and make sure that I'm not blindly indoctrinating myself into some idealistic nonsense before I have much in the way of real world experience.

I've seen the debates against TDD online, and Uncle Bob himself warns against trying to adopt things like TDD and Agile too quickly, as they're intended to be skills and disciplines that one has to practice to become effective at.

My question is simply this, if anyone would like to share their opinion:

Why might TDD ever be a bad idea?

or:

Why is TDD always a good idea?

Expectate: A Go Testing Utility

Steven Kaufman — Tue, 22 Dec 2020 07:34:29 +0000

Do you love the simplicity of Go testing but hate writing if statements constantly?

Do you like the 'expect' style syntax of testing libraries like jest in JavaScript but don't care for Gomega?

The answer:

Expectate

github.com/gomagedon/expectate

Why is Expectate better than Gomega?

Well, that's a matter of opinion. The main differences are:

Expectate is simpler
The syntax is a little different (closer to jest)

How is it simpler?

If you've ever used Gomega (the Ginkgo assertion tool)...

You wouldn't describe it as simple. It does a lot. Like a lot a lot. There are a lot of ways to write the same thing. For example:

err := DoSomethingSimple()
Ω(err).ShouldNot(HaveOccurred())

Is the same as:

Ω(DoSomethingSimple()).Should(Succeed())

And that's not to mention the Expect syntax:

g.Expect(DoSomethingSimple()).To(Succeed())

And those are just the different ways to assert that an error is nil!

The Expectate Way:

err := DoSomethingSimple()
expect(err).NotToBe(nil)

That's it.
No alternative syntax.

In fact, Expectate has only 4 methods!

ToBe()
ToEqual()
NotToBe()
NotToEqual()

ToBe() checks for simple equality, i.e. var1 == var2

ToEqual() checks for deep equality using google/go-cmp

NotToBe() and NotToEqual() check for the opposite cases just like you would expect! (pun intended)

That's all it does?

Yeah. So what?

It's all syntactic sugar. The whole point is to turn a three-line if statement into one line that looks nice and pretty. Gomega doesn't actually provide much more functionality, just more ways to write the same thing.

Expectate is real nice and lightweight 😎

If I download the latest version of Gomega from GitHub, guess how big the zip file is?

Gomega size:

gomega-1.10.4.zip: 163K

Compared to Expectate:

expectate-1.0.0.zip: 7K

Not to mention that all the production code for Expectate is in a single file, and 80% of that 7K is probably the tests.

So this is just another stupid testing library that doesn't do much?

Right again.

Don't use it for everything!

If you want a more descriptive error message than foo is not bar, just use testing.T like normal!!

A Note On Compatibility

Expectate doesn't have to use testing.T (although you really should)!

Typically you would write an Expectate test like this:

func TestFooIsBar(t *testing.T) {
  expect := expectate.Expect(t)
  expect("foo").ToBe("bar")
}

And the output:

-------- FAIL: TestFooIsBar (0.00s)
    expect.go:34: foo is not bar

The above example uses testing.T (as our lord and savior Rob Pike intended)
But you can use any object that satisfies the Fataler interface!

type Fataler interface {
  Fatal(args ...interface{})
}

So anyway check it out! It's my very new project, so please give lots of feedback, positive or negative! Open all the issues!