Go R1 Day 62

2021-08-04 365 words 2 minutes

progress

Worked with mocks.

Still using the is package to test.

1
2
3


if !reflect.DeepEqual(want, spySleepPrinter.Calls) {
  t.Errorf("wanted calls %v got %v", want, spySleepPrinter.Calls)
}

was replaced with:

1

is.Equal(spySleepPrinter.Calls, want) // spySleepPrinter shows correct order of calls

Go is messing with my head with how everything gets simplified to the lowest common interface when possible. Instead of buffer, I’d want to use io.Writer for example. This abstraction is where there is so much power, but it requires a deeper understanding of following the dependency tree to know what properly satisfies the interface. I’m finding that one layer isn’t enough sometimes with lower level interfaces, and requires getting comfortable with more low level packages from the standard library. Pretty cool that I didn’t need to do anything more complex to do a comparison.

When To Use Mocking

Without mocking important areas of your code will be untested. In our case we would not be able to test that our code paused between each print but there are countless other examples. Calling a service that can fail? Wanting to test your system in a particular state? It is very hard to test these scenarios without mocking. ¹

Other Good Insights

“When to use iterative development? You should use iterative development only on projects that you want to succeed.”

Martin Fowler

I really agree with this next quote. I’ve seen this happen so often with the pressures of a project, and feel it’s the excuse that causes the escalation of technical debt that becomes difficult to untangle retroactively.

Try to get to a point where you have working software backed by tests as soon as you can, to avoid getting in rabbit holes and taking a “big bang” approach. ¹

Go R1 Day 62

progress

When To Use Mocking

Other Good Insights

links

Webmentions