Should You Unit Test Private Methods?

To unit test private methods or not to test, that’s the question. There are two kinds of software developers in this world: those who never subject private methods to unit testing directly and those who do. Let’s look at both sides of the arguments to understand this better.


Performance Testing Serverside Applications

Performance testing server-side applications is a crucial process to help understand how the application behaves under load. It helps software teams fine-tune their applications to get the best performance while keeping the infrastructure costs low. Performance testing answers several important questions such as:

  • Is the application ready to handle the traffic that’s going to hit it?
  • What do average response times and latencies look like under normal and peak loads?
  • Can the application be scaled out?
  • What are the bottlenecks? (could be CPU, memory, an external service or a database server)
  • How many instances are needed for supporting the estimated traffic (i.e. max RPS)?
  • What type of instances are needed? Does the application requires an instance with higher CPU to Memory ratio? Or does it need an instance type that supports high network utilization?
  • Does the application slowly degrade in performance under load? Is it slowly leaking a resource that eventually crashes it after a few hours or days?

Taking Responsibility for Your Actions

I read Pragmatic Programmer whenever I get a chance. It’s such a great book. I was skipping through the pages today and landed on the first chapter. After (re)reading it, I can say that it is arguably the best chapter in the book. All software developers must read it once and live by its philosophy:

One of the cornerstones of the pragmatic philosophy is the idea of taking responsibility for yourself and your actions in terms of your career advancement, your project, and your day-to-day work. A Pragmatic Programmer takes charge of his or her own career, and isn’t afraid to admit ignorance or error. It’s not the most pleasant aspect of programming, to be sure, but it will happen—even on the best of projects. Despite thorough testing, good documentation, and solid automation, things go wrong. Deliveries are late. Unforeseen technical problems come up.

In your career, you will make mistakes. They are inevitable. I can’t count the number of times I have made mistakes. So when you do make a mistake for something you accepted responsibility for:

  • Don’t deflect responsibility.
  • Don’t blame another team member.
  • Don’t blame a vendor.
  • Don’t blame a library or a tool that you use.
  • Don’t blame management.
  • Don’t become defensive.

Git Tips - Undoing Accidental Commits

Here are couple of git undo’s to get yourself out of trouble. Before you use anything from this post, please make a copy of the your working directory and store it somewhere safe. Git can be very unforgiving and you may lose your changes without any warning.


Automated Tests Help Developers Sleep Better

In Pragmatic Programmer, Andy and Dave wrote:

Most developers hate testing. They tend to test gently, subconsciously knowing where the code will break and avoiding the weak spots. Pragmatic Programmers are different. We are driven to find our bugs now, so we don’t have to endure the shame of others finding our bugs later.

There hasn’t been any shortage of literature on the benefits of automated testing in the last 10-15 years. Yet it comes as a surprise to me that most developers still don’t like to write unit tests. Some managers force developers to write tests by making an arbitrary code coverage number mandatory for releases. This is dangerous because the result is often low quality and ineffective tests that do not catch the bugs that they were supposed to.