karlseguin/expect

A testing framework for Go

Hi.

Lately, I've largely been writing Zig libraries. If you're interested in learning Zig, check out my Learning Zig series of blog posts.

• pg.zig - native PostgreSQL driver
• http.zig - An HTTP/1.1 server
• websocket.zig - A websocket server
• mqttz - Allocation free, no sdlib required MQTT client
• logz.zig - Structured logger
• metrics.zig - Prometheus metrics library
• zqlite.zig - A thin wrapper for sqlite
• zuckdb.zig - A thin wrapper for duckdb
• cache.zig - Thread-safe, expiration-aware, LRU cache
• smtp_client.zig - An SMTP client
• validate.zig - A validation library
• singleflight.zig - Duplicate function call suppression
• zul - zig utility library
• buffer.zig - A poolable string builder (aka string buffer)
• aolium-api - a blogging / link sharing platform
• duckdb-proxy - An HTTP proxy for DuckDB

I also have a few Elixir libraries you might find useful:

• exws - A minimalist Websocket server for Elixir (+ channel library)
• dcache - A fast caching library for Elixir

And a few low-friction services:

• goblgobl/assets - A performance-focused static asset proxy
• goblgobl/authen - An authentication enhancement service

My most popular repos are:

• ccache - An LRU caching library for Go
• the-little-go-book - The Little Go Book
• the-little-redis-book - The Little Redis Book

Semi-retired, but always open to hearing about opportunities. Contact on my blog.

expect's Issues

Go 1.13: one shall not call flag.Parse() in init

See bug golang/go#33475 and bug golang/go#31859 for the rationale

To be clear, we are talking only about flag.Parse here, not flag.*. The flag package is designed so that multiple packages can define flags, without those packages being aware of each other. It's essential that flag.Parse be called only after all flags are defined, meaning only after all packages are initialized. The normal practice is that the main package calls flag.Parse, because the main package is the only package that is sure to run after all packages are initialized.

Your program may well be designed so that it is OK to call flag.Parse in an init function of some non-main package. But most programs do not and cannot work that way. So I am questioning how much we should twist the testing package to support that use case. Of course if the change to the testing package is simple, then that is fine. But I would not like to see a lot of complexity added to support a very unusual use case.

I've read that you don't do much Go anymore, but it would be great if you could keep your package functional for Go 1.13 and further.

Remove call to flag.Parse from init

Calling flag.Parse from init is incorrect, since other packages may still want to register flags.

In Go 1.13, calling flag.Parse in init from a test is more likely to break, so users of this package will likely crash. See golang/go#33475 and golang/go#31859 for context.