DEV Community

Why I don't use a third-party assertion library in Go unit tests

Yawar Amin on May 20, 2024

TL;DR: I don't need it, and you probably don't either. I'll explain below. As we know of course, Go ships with a built-in unit testing framework i...
Collapse
 
bcamphart profile image
B. Camphart

My philosophy is to not introduce any external dependency until I absolutely need it. Creating a small assertion helper function that you have total control over is better than pulling in a dependency that you have no control over. Until the project absolutely needs all the extra features that an external dependency provides, it's more maintainable to roll out simple functionality yourself.

Collapse
 
alaindet profile image
Alain D'Ettorre

I wrote my assertions too until I moved to another project and had to copy-paste them all. Testify is great, it's worth it.

Collapse
 
antoine_toussaint_05992e5 profile image
Antoine Toussaint

Why would you care about adding an external dependency for your tests? They won't even be included in your runtime binaries.
The point is that your own implementation will cover a lot of test cases (99%) but when you get to that 1%, then you have to add the external dependency anyway so all the work you did before goes in the trash.

Collapse
 
yawaramin profile image
Yawar Amin

It's not just about how heavy the runtime binary is, it's also about how much third-party code I am depending on. By introducing a new dependency, I am now relying on a third party's unpaid efforts. If I can avoid that with less than 15 lines of code, why shouldn't I?

Sure, I might end up needing more advanced assertion libraries. But why borrow problems from the future? If I need something in the future, I'll use it. And nothing is going to go 'in the trash' because I'll just keep using my own assertion whenever possible anyway.

Collapse
 
antoine_toussaint_05992e5 profile image
Antoine Toussaint

You say "By introducing a new dependency, I am now relying on a third party's unpaid efforts."
which effort? What fact do you have to back it up? Maybe I am wrong, but you make strong points and they need proof.

Thread Thread
 
yawaramin profile image
Yawar Amin

What facts and proof are you looking for? When you use an OSS library maintained by someone, that person has to spend some effort to maintain the project–writing code, triaging issues, responding to queries, doing code reviews, tagging releases. The OSS doesn't magically maintain itself out of thin air.

Thread Thread
 
antoine_toussaint_05992e5 profile image
Antoine Toussaint

So you don’t rely on OSS at all?

Thread Thread
 
yawaramin profile image
Yawar Amin

Of course I rely on OSS, as almost every developer does. But I want to be able to pick and choose which OSS I rely on and I want to reduce my dependency surface area as much as possible. If I can get 90% of the benefit of a third-party library with less than 15 lines of hand-written code that I know like the back of my hand, why shouldn't I just do that?

Collapse
 
psydvl profile image
Dmitriy P

So, you don't use third-party assertion library just because you wrote new one by yourself

Collapse
 
ccoveille profile image
Christophe Colombier

I thought the article was about using fmt.Println + // want: whatever

But no 🤔

Collapse
 
dehypnosis profile image
dehypnosis • Edited

it seems that you wrote a tiny testify by yourself. why?

Collapse
 
antoine_toussaint_05992e5 profile image
Antoine Toussaint

By writing your own thing instead of using well-known, quasi-standard way of testing, you also hurt uniformity and ease of collaboration since people have to learn your API instead.

Collapse
 
yawaramin profile image
Yawar Amin

So just to clarify, are you making both arguments at the same time:

  1. My assertion function is too simple and won't cover the last 1% of test cases that might be needed
  2. I am placing a heavy burden on my team to learn this one simple, well-documented, self-explanatory function

?