<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Internals on gotest</title><link>https://mvrahden.github.io/go-test/tags/internals/</link><description>Recent content in Internals on gotest</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 06 Sep 2026 10:37:08 +0200</lastBuildDate><atom:link href="https://mvrahden.github.io/go-test/tags/internals/feed.xml" rel="self" type="application/rss+xml"/><item><title>Code Generation vs Reflection in Go Test Frameworks</title><link>https://mvrahden.github.io/go-test/blog/code-generation-not-reflection/</link><pubDate>Thu, 09 Jul 2026 00:00:00 +0000</pubDate><guid>https://mvrahden.github.io/go-test/blog/code-generation-not-reflection/</guid><description>&lt;p&gt;Every Go test framework that supports suites needs to solve the same problem: how do you connect a struct full of test methods to the &lt;code&gt;go test&lt;/code&gt; runner? The runner only knows about top-level &lt;code&gt;func Test*(t *testing.T)&lt;/code&gt; functions. Your suite is a struct with methods. Something has to bridge the gap.&lt;/p&gt;
&lt;p&gt;Most frameworks use reflection. gotest uses code generation. This post explains why, and what the code generation pipeline actually does.&lt;/p&gt;</description></item></channel></rss>