🧣 Mood: Wearing many layers inside to avoid turning on the heat.

🎵 Soundtrack: Ghibli, Anime & Chill

📚 Reading Github Issues

Nothing exciting. I think the number of issues has been cooling down because code freeze is coming soon.

🩺 Making My “Fix All” Code Action

For the past days I have been playing around with making my own silly diagnostic and code action. I’ve been doing this to gain familiarity with the gopls codebase and eventually fix this issue, which is about adding a “fix all” option when you highlight a section of code in your editor that has multiple diagnostics.

So far my route has been:

  • Build gopls locally and use my local copy when using VSCode.
  • Build my own diagnostic that suggests a change from “amelia” -> “ameowlia”.
  • Build a “mega” code action that shows up when you highlight code with multiple problematic “amelia”s and suggests fixing them all at once. ✨ I finally got this working today with a version that does NOT crash or cause the blue box of death or fix things incorrectly or fix things multiple times.
  • Improve on the previous step by building a generic “mega” code action that will group all similar diagnostics and allow you to fix them together. ✨ I also got this working today!!!!

🎉 So I finally figured out how to make my “mega” code action and where to put it….. but the code is hacky and def not prod ready. The next step is to write some tests and refactor!

I took a look at the tests that are there and they are kinda inscrutable and rely heavily on testdata files and specifically golden files, which I have never heard of before. I guess it is time to learn.

👑 Golden Files

🎥 I watched GopherCon 2017: Mitchell Hashimoto - Advanced Testing with Go. I found this video because it has a section on Golden Files, but it was also a good talk about testing in general.

I learned:

  • Golden files are a way to compare complex test output to a file that has the expected result.
  • You could read in the golden file and then do a bytes equal or you could do something more sophisticated.
  • go test sets pwd as the package directory. Which is why testdata is always stored relative to the package being tested, regardless of where the test is actually located.
  • Test helpers should never return an error. They should just fail the test so you don’t have to be making your test more confusing with lots of error checking.
  • You can add t.Helper() to the top of your test helpers. This will give you better stack output if your test fails in the helper. It will help you determine which test was running that failed.

📌 Other Golang Updates

Some other changes I submitted got merged or moved forward: