Here's the thing with TDD: until you work on a project that's either
a) contributed to by a lot of developers that aren't familiar with the source code,
b) so large that you're scared of making any substantial changes because the last time you did that another piece broke and it took forever to figure out it was actually broken and another forever to figure out how to get both pieces working together and in the process you half-broke this other piece and GAH maybe I should just rewrite the entire thing, or:
c) mission-critical, where a piece not doing what it's supposed to means lost lives or money,
then TDD is a net waste of time. Much like learning git, you'll be fighting an uphill battle with your mind at every stumbling block ("ugh this is so complicated - why am I learning this again? Doesn't putting my source code in Dropbox solve all of these problems already?") until you have an actual, real, legitimate use for the solution ("oh right, I'm learning git because using Dropbox to collaborate means 'conflicted copy' city").
Tests don't have to be complicated. They don't have to use the next new shiny framework, they don't have to have a smart lookup system that auto-runs files that are checked in and sends you an email if you push bad code; tests are just if statements, and they're mostly the if statements that you're already running through your mind when you program. Here's a hopefully not too contrived example:
When you wrote commit 4a069[1], how did you know the code you wrote actually did anything? From my quick understanding of reading this over, it looks like you changed `padding` and `size` from constants (5 and 30 respectively) to variables set somewhere else (in `utils.go`). If you made all these changes at once, then re-ran whatever code you use to make a penticon, the expected behavior is that you'd see the exact same thing as before (test#1).
But wait, were you even editing the same file you ran? Let's double `Padding` and `Size` in `utils.go` and make sure it changes the image (test#2). Alright cool, it does. But wait, the padding looks way too big - is it twice what it needs to be? Let's try `Padding = 1` and `Padding = 0` and make sure that looks how I expect it to (test#3, test#4). Awesome - that's perfect.
Does the size work too? I wonder if this would break if the `Size=0` (test#5). Oh shoot, what if both the size and padding were 0 (test#6). OH SHOOT WHAT IF THEY WERE NEGATIVE? (test#7).
---
All of that to illustrate: the difference between what you're (probably) doing right now and TDD is that in TDD you write down each test as you're testing it. At the end of adding those two variables you'd have a second file of 7 if statements that make sure that changing the size and padding works like it's supposed to.
Unfortunately, `penticons.go` is a horrible project to bring TDD into your workflow because 1) it's tiny and can probably fit in your head all at once so you'll know immediately anyway if something breaks, and 2) testing images is hard. It looks like a lot of your other public projects are equally as TDD-unnecessary.
What you could do is generate a bunch of references images (like a 1x1px empty image for when the padding=1 and Size=0), then write a script that runs the code that should generate the same image and make sure they match bit-for-bit. Again, though: until you're feeling the pain that having the piece of mind that no other part of your program was just broken by what you did, you don't need to add TDD to your workflow.
1. https://github.com/penticons/penticons.go/commit/4a069619545...