<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Philosophy on gotest</title><link>https://mvrahden.github.io/go-test/tags/philosophy/</link><description>Recent content in Philosophy 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/philosophy/feed.xml" rel="self" type="application/rss+xml"/><item><title>BDD in Go: What Behavior-Driven Development Actually Means</title><link>https://mvrahden.github.io/go-test/blog/what-bdd-means-in-go/</link><pubDate>Mon, 13 Jul 2026 00:00:00 +0000</pubDate><guid>https://mvrahden.github.io/go-test/blog/what-bdd-means-in-go/</guid><description>&lt;p&gt;BDD — Behavior-Driven Development — is one of the most misunderstood ideas in testing. Most developers encounter it as syntax: &lt;code&gt;describe&lt;/code&gt;, &lt;code&gt;context&lt;/code&gt;, &lt;code&gt;it&lt;/code&gt;. They learn the keywords, use them in a few test files, and assume they are doing BDD. But BDD is not syntax. It is a communication practice. And Go&amp;rsquo;s type system makes it possible to do BDD without the ceremony that other languages require.&lt;/p&gt;
&lt;p&gt;This is not a tutorial on &lt;code&gt;When&lt;/code&gt; and &lt;code&gt;It&lt;/code&gt; — that is covered in &lt;a href="https://mvrahden.github.io/go-test/blog/readable-tests-with-bdd/"&gt;Readable Go Tests with BDD-Style Subtests&lt;/a&gt;. This post is about the idea behind BDD, why most implementations of it carry unnecessary weight, and how Go&amp;rsquo;s type system maps to BDD concepts in a way that is unique among programming languages.&lt;/p&gt;</description></item><item><title>Why Go's testing Package Needs a Suite Layer</title><link>https://mvrahden.github.io/go-test/blog/why-gotest/</link><pubDate>Sun, 05 Jul 2026 00:00:00 +0000</pubDate><guid>https://mvrahden.github.io/go-test/blog/why-gotest/</guid><description>&lt;p&gt;Go&amp;rsquo;s &lt;code&gt;testing&lt;/code&gt; package is one of the best things about the language: no framework to install, no annotations to learn, just &lt;code&gt;func Test*&lt;/code&gt; and &lt;code&gt;go test&lt;/code&gt;. But past a few dozen test files, most projects hit the same wall. There is no way to group related tests, no per-test setup hook, and no way for two packages to share a database container.&lt;/p&gt;
&lt;p&gt;That is not because the design is wrong, but because &lt;code&gt;testing&lt;/code&gt; is deliberately minimal. It gives you a test runner and an assertion-free &lt;code&gt;T&lt;/code&gt; type. Everything else is left to the developer: organizing tests into groups, managing setup and teardown, sharing expensive infrastructure, expressing what a test &lt;em&gt;means&lt;/em&gt; rather than just what it does.&lt;/p&gt;</description></item></channel></rss>