There are some out there in the industry that will swear by the criticality of test coverage. The conclusion seems to be that 100% test coverage equates to 100% correctness. However, that simply isn't true in all cases.
All posts in Best Practices
When something works well enough, for long enough, with enough support, from enough people, it becomes a well known way to approach a particular situation and get things done.
Most any programming language has a way to express nothing, whether it's NULL, null, nil, or even None. But, what is nothing? Can nothing be something? More importantly should nothing ever be something?
Error handling is a critical aspect to making stable, maintainable software, and APIs are no exception. The single biggest source of ambiguity in API error responses I've found is the improper use of HTTP status codes.
There's one idea I've seen reiterated over and over again in relation to the Go language. What if it's actually fine?
There's a huge difference between unit testing, and effective unit testing. I wanted to take the time to clarify such a critical (and often overlooked) practice in development.
I think that by now, most of us in the development community have heard about Test Driven Development and Behavior Driven Development, but how many people do you know that have consistently applied these practices and got the ROI from it?