<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Golang on Lobocv Blog</title><link>http://blog.lobocv.com/categories/golang/</link><description>Recent content in Golang on Lobocv Blog</description><generator>Hugo -- gohugo.io</generator><lastBuildDate>Sat, 01 Oct 2022 00:00:00 +0000</lastBuildDate><atom:link href="http://blog.lobocv.com/categories/golang/index.xml" rel="self" type="application/rss+xml"/><item><title>Testing complex workflows in Go</title><link>http://blog.lobocv.com/posts/golang_testing/</link><pubDate>Sat, 01 Oct 2022 00:00:00 +0000</pubDate><guid>http://blog.lobocv.com/posts/golang_testing/</guid><description>The standard library testing package in Go does many things well. It is simple to use and executes fast and efficiently, even running tests in parallel and the caching results. However, many including myself, have turned to supplemental packages to address some blind spots when writing tests:
Test setup, teardown and grouping Assertions and output validation Mocking I have found that these blind spots become particularly cumbersome when you have workflows that involve sophisticated fixture setup, multiple edge cases, error handling, mocks, and complex outputs.</description></item><item><title>Advanced Go Error Handling Made Simple</title><link>http://blog.lobocv.com/posts/richer_golang_errors/</link><pubDate>Tue, 22 Mar 2022 00:00:00 +0000</pubDate><guid>http://blog.lobocv.com/posts/richer_golang_errors/</guid><description>One of the most notorious design decisions of Go is how it approaches error handling. Go handles errors explicitly by returning them as values from any function that can possibly raise an error. To many, this way of error handling is uncomfortable at first. The tediousness of having every function not only return an optional error but also check the returned error from every function seemed to be too tedious.</description></item></channel></rss>