Check out all the formatting styles, text options, blocks, and features available for your posts on this platform.
Check out all the formatting styles, text options, blocks, and features available for your posts on this platform.
Check out all the formatting styles, text options, blocks, and features available for your posts on this platform.
Go examples with parameters or results can appear in documentation without becoming tests.
Project Calavera is a CLI tool that scaffolds linters, formatters, AI tooling, and common project infrastructure for web projects. Calavera âĪïļ Vite. This post walks through the full contribution path for a new integration, using the Varlock PR as a concrete example.
Far far away, behind the word mountains, far from the countries Vokalia and Consonantia, there live the blind texts. Separated they live in Bookmarksgrove right at the coast of the Semantics, a large language ocean. A small river named Duden flows by their place and supplies it with the necessary regelialia. It is a paradisematic country, in which roasted parts of sentences fly into your mouth. Even the all-powerful Pointing has no control about the blind texts it is an almost unorthographic lif...
A practical guide to thinking about what to test and why, using Vitest as my tool of choice. Covers the happy path, conditionals, purity, and the limits of code coverage as a measure of test quality.
css-expect enables you to write unit tests for your CSS @functions using the browser engine itself as the source of truth.
Most of the now-playing kiosk was built with my autopilot workflow, which I've written about before. I describe a feature, it gets planned, built, and reviewed, and it ships. For most of the project that's the whole story. But the kiosk's job is to recognize records playing on a real turntable through a real audio chain, and the autopilot has no way to drop a needle and check that what it built actually works. For anything that touches the hardware, "the autopilot shipped it" isn't the same as "
How cmd/go's script tests led me to testscript, and how to use it for CLI tests that exercise argv, stdout, stderr, exit codes, and scratch files.
Knowing when you've tested enough depends on whether you can see the edges of your input space.
txtar is a tiny plain-text archive format Russ Cox introduced in 2018 for multi-file test fixtures. The Go Playground, cmd/go's script tests, gopls's marker tests, and rsc.io/rf all reach for it.
I've been working with Claude Code long enough that the laughably bad time estimates have become background noise. Claude thinks a 90-second task takes 30 minutes. I ask it to plan a sprint that I know we can do in a few days and it thinks it will take weeks. It's annoying but easy to ignore. What's harder to ignore is what happens when you introduce a deadline â tell Claude it's end-of-sprint, a demo is tomorrow morning, something needs to ship today and the behavior changes. And because the
How to test unary gRPC services in Go - handler logic, interceptors, deadlines, metadata propagation, and rich error details - all in-memory with bufconn.
Most library maintainers have no way to test against their dependents before releasing.
AI agents can generate code 100x faster, but for companies stuck in the "Unhappy Middle" â with legacy debt, bespoke frameworks, and zero slack â the bottleneck has shifted from writing code to verifying it. Here's how engineering leaders can cross the chasm by becoming gardeners, not janitors.
Resources and learning materials for getting started with Vitest in Svelte & SvelteKit
I have yet to decide what I want to do with this blog, even though I have ideas... I have multiple Leaflet publications, I have multiple WordPress blogs, I have active profiles just about everywhere and I really don't need another blog - but I want one ð I've been busy experimenting with all the new ATproto tools and this is another one on the list! So, for now, I'm just experimenting with the blocks available on pckt and hopefully it'll give me some inspiration and direction of where to go from...
Joel Griffith explains how Browserless runs headless browser automation at scale and introduces BrowserQL for querying the web with SQL-like syntax.
Practical patterns for mocking in Go without external libraries. Learn to mock functions, methods, interfaces, HTTP calls, and time using only the standard library
just testing
Master shadow testing for large-scale system migrations. Learn to safely rewrite services by comparing outputs between old and new implementations.
Test Go subprocesses with the re-exec pattern: spawn your test binary as a subprocess to emulate real command behavior reliably.
Apply SOLID's Interface Segregation Principle in Go with consumer-defined contracts. Learn why small interfaces and implicit implementation matter.
Organize Go tests with in-package, external _test packages, and integration tests. Learn white-box vs black-box testing conventions.
Organize Go subtests with t.Run nesting and parallel execution. Learn patterns for setup, teardown, and readable test hierarchies.
Avoid brittle AI-generated tests that check implementation details. Write maintainable tests that verify behavior, not method calls.
Prevent goroutine leaks caused by early returns with unbuffered channels. Learn buffering, draining, errgroup patterns, and goleak testing.
Master Go test lifecycle with t.Cleanup(), subtests, and TestMain. Learn per-test, grouped, and package-wide setup patterns effectively.
Control Go test behavior with custom flags instead of build tags or env vars. Enable integration and snapshot tests with discoverable CLI options.
Dependency injection in Go doesn't need Dig or Wire. Learn why manual wiring beats reflection magic and how Go's design makes DI frameworks overkill.
Test functions that write to stdout/stderr in Go by capturing output with os.Pipe. Learn patterns to avoid deadlocks in concurrent tests.
Return teardown closures from test helpers to manage cleanup elegantly. Learn patterns for temp files, mock servers, and t.Cleanup() usage.
After a mere ten years of writing code professionally, I have finally attempted to start a project by writing out tests for its core functionality first. Apparently this is a whole thing. Who knew? I tend to fall into the Grug school of thought on testing. A lot of the time I don't think it's super worthwhile to start writing tests before I really understand the problem space of a project, especially since historically I've switched frameworks and tools so often that the first few weeks of work