Coding

In the previous posts, we examined the Why, When, and How Much of testing. In this post, we will complete the thread with an examination of What we should be testing and What we should not be testing.

In the previous post, we examined the Why and When of testing in this post, we will build on that foundation and look at How much we should be testing.

When it comes to testing, the most common misunderstanding is the motivations of testing itself. Some folks see testing as a burden imposed from on high. Some folks see testing, or more specifically, test coverage, as a metric that determines how well they did their job. Sorry, but neither of these is true. This post will address these fallacies and give you a different perspective on testing.

The following content is a small extract from my latest book Beyond Effective Go – Part 1 – Achieving High-Performance Code. Slow consumers When designing function...

A small extract from my latest book about deadlocks

Have you ever added a new feature only to have another one break?  After fixing the break, something else breaks, like some kind of bug whack-a-mole? Have you ever...

There seems to have been a lot of talk around me lately in relation to "dev boxes" and "testing on staging". After unsuccessfully trying to convince folks of why I think this is a bad...

This post can also be found on the Grab Engineering blog Perhaps one of the biggest missed opportunities in Tech in recent history is UX. Somehow, UX became the domain...

When I tell people, "No transactions!" their first reaction is either "he's mad" or "for my use-case its necessary". I know this was my reaction when it was first said to me. I happened to be working on a money...

Last week I was privileged to give a talk to the Singapore Gophers meet up held at the GrabTaxi Singapore Tech Office. The talk was titled "Dependency Injecting (and Testing)" and was inspired by this great article...