This Is Why We Don't Test Private Methods

Trying to test private methods causes a lot of confusion.

That’s a common question we all have made when finding unit testing for the first time. These days, I found that very same question on Reddit:

Can someone explain to me why unit testing our private methods is bad?

Because we don’t want to break encapsulation.

If you have a private method, how are you going to call it from a test class or method? It’s private. You can only access it from inside the same class. That’s the whole point of access modifiers: restricting access to the fields and properties that hold the internal state of a class.

And please don’t make your private methods public and static to call them directly inside unit tests. They’re private for a reason, right? We don’t want the rest of your code to use them directly.

Exposing internals is the most common mistake when writing tests. I’ve seen it and fixed it before.

Let’s take the HasAdmin() method from the question as an example,

private bool HasAdmin(List<string> relations, bool hasPermission)
{
    // Beep, beep, boop...
}

Unless HasAdmin() has 0 references—if that’s the case, you should remove it—another method from the same class is calling it. And you can trace the chain of method calls back to a public method.

HasAdmin(), or any other private method down in the chain of method calls, is changing something that you can observe from public methods. Probably it’s affecting a return value or changing an internal state you can inspect with getters. That’s what you should test instead.

To test HasAdmin(), create a User object with the right relations and permissions, call the public methods you have, and check what should change when your user is an admin or not. Maybe you return additional data only admins can access or finish an action without throwing a UnauthorizedAccessException.

You test private methods indirectly while testing the observable behavior exposed through public methods.

Et voilà!

To read more about unit testing, check how to write your first unit test in C# with MSTest and four common mistakes when writing your first unit tests. Don’t miss the rest of the Unit Testing 101 series.

Always Be Reading. But Reading More Isn't Always the Answer

Before finding “The Almanack of Naval Ravikant,” I was a ferocious reader.

I was in the “let’s read as many books as we can” team. By pure FOMO, I was trying to follow YouTube trends like “I read 9,999 books about money, here’s what I learned” and the mantra “read one book per week.”

But out of dozens of books I had read, I didn’t remember reading some of them, even when I had notes. I kept one or two ideas from those books in the back of my head but I couldn’t trace them back to where I found them.

Then I found Naval’s reading strategy. Ironically, by reading another book.

Instead of reading as many books as possible, he reads and rereads a few good ones. The ones that have passed the test of time. He meditates on their lessons, acts on them, and then he uses X/Twitter to take public notes.

Naval’s reading strategy changed my mind about reading:

• I don’t have to read books from cover to cover. I can jump straight to a chapter or section to find an answer.
• I can leave books unfinished. For someone trying to increase a book count, leaving books unfinished made it hard to count. If I read only half of the book, should I add 0.5 to my tally?
• It’s OK to reread books. Again, rereading didn’t contribute to my increasing book count.

And more important than reading to increase a book count is acting on what we read. Remember, passive learning is just entertainment.

Once you read a book, write 10 lessons you learned from that book, and find one lesson you can act on immediately. That’s more valuable than a large book count without any taking any action.

Find Your Producer's Switch

That’s Leland Sklar’s strategy, a well-known bass guitar player and session musician. He’s appeared on over 2,000 albums, based on his Wikipedia profile.

While recording in a studio, if a director asked him to change the sound, he simply turned on or off a fake switch and continued playing.

This is what he said during an interview for Guitar World:

“If I’m on a session and the producer asks me to get a different sound, I make sure he sees me flip this switch and then I just change my hand position a bit. There are no wires or anything that go to this switch. It’s a placebo, but it’s saved me a lot of grief in the studio.”

That’s genius!

What would be a director’s switch for coders? A typo in a variable name, missing brackets on 1-line conditionals, misaligned elements on a screen, writing SELECT * instead of SELECT with a list of columns.

What would you add?

The Easiest Way to Be Ignored When Communicating at Work

Only send “Hello, how are you?” in Teams or Slack at work.

You’ll get ignored immediately. Especially if you’re working in a remote team with people all over the world. And especially if you’re reaching out to a busy manager or executive.

That’s how that “Hello, how are you?” conversation will look:

• Hello, how are you?
• …
• Good, thanks. And you?
• …
• Good too, thanks.
• Hey, I just wanted…

But, what if your recipient is on the other side of the world? 24 hours could pass between each message. And for sure, you don’t want to wait 48 hours to start the real conversation.

While working remotely at a past job, I used nohello.net as my Slack status. That page shows a fake “hello, how are you?” conversation, getting ignored. And I still got “Hello, how are you?” messages. Arrrggg!

Would you send an email saying just “Hello, how are you?” You wouldn’t, right? Then, why do the same on Slack or Teams at work?

Next time you want to reach out to someone at work, don’t send “Hello, how are you?” Say hi and in the same message, without waiting for an answer, say what you really want to say.

That should be “Remote Working 101” when onboarding new team members at any remote company.

Did You Have a Mentor, and Did It Help You?

That’s question I found on dev.to. Here’s my full answer:

I’ve had mentors. But, not formally and without the label.

I can pinpoint two or three people in my career that were like “mentors.”

At a past job, I had the chance to work next to my team architects and learned a lot from them. From the value of reading other people’s code to rejecting requests politely. Here are some of those lessons, by the way.

And at another job, one day I decided to reach out to my boss’ boss with genuine questions, not related to the job. He was open and kind enough to answer them. He liked reading books too and we connected on that. From that point, we started to have 1-1s outside the usual meetings. He recommended a long list of books to me.

If you’re looking for a mentor, don’t ask anyone to “be your mentor.” That would imply commitment from one side. Most of the time, for free.

Instead of asking someone “to be your mentor”:

1. Approach him with genuine questions: Bring your own challenges and how you’re trying to face them. Ask what he would do if he were in your shoes.

2. Show interest in him: Ask your “not-mentor” about his career progression and choices. People like talking about themselves.

3. Help him somehow too: When I found books my not-mentor would like, I also brought them to our conversations.

4. Show you’re taking action on the advice or input you’re given: I followed up with my not-mentor, sharing lessons I learned from the books he recommended to me.

With those four steps, you will be in a mentorship—without even realizing it.

But, don’t worry if you don’t have a mentor or can’t find one.

Mentors are everywhere. The good thing is you don’t have to meet them. 200-500 books are a good mentor. I learned that from James Altucher, a mentor I haven’t met.