I’m a big fan of TDD. BDD has always been a bit elusive to me in the sense that I wish I could use it more often. However, I always seem to end up struggling to express the same nuances through BDD that come effortlessly through a standard test case.
Truth be told, I have’t touched BDD in a while. However, this question has been bouncing around my head lately:
Why is it often so difficult to express simple systems through BDD?
Code based tests are really good at describing how we complete a task. BDD is really good at describing what a task is trying to achieve. …
Go’s error handling is very explicit. It can also be very verbose compared to other languages. I want to talk about how we can minimize the need for explicit error handling by separating what are expected and unexpected errors.
An expected error is generally something you can test/check/verify ahead of time or that would not have a detrimental effect on the system. Some examples of expected errors are:
Expected errors should always return an error. This lets the caller decide what to do in this case. It may want to bubble the error up, or it may choose to bail out of the current operation. …
Go does not have any concept of enums like some other languages. There are arguments for and against this approach which I won’t go into here. However, there are times when you want to check that
switch statements contain all enum values. Especially if you intend to add new enum values in the future and want to catch existing code that now needs to be updated accordingly.
go get -u github.com/elliotchance/switch-check
Or, here is a quick…