6 ms·
Go Testing by Example [video]
- ijustlovemath 3y agoSeparating test data and test logic is exactly how we have built our test infrastructure to satisfy the FDA; making clear test data that you can then query and report on gives you tons of nice features for free! It also really helps you to properly model your problem by breaking things out into their simplest possible components, and makes porting to a new implementation a breeze; reproduce a quick test data parser and some simple case logic, and you're well on your way to having two totally matching, but also totally separate, implementations! ...all of this without reinventing Lisp, of course ;)
- GamerAlias 3y agoHaving not really written many tests before due to having worked moreso as a data scientist (a smidgen of pytest here and there), it's so nice writing tests in Go. Definitely a considered and well implemented part of the language
- deleted 3y ago[deleted]
- mcint 3y agoWow! Someone brought up and demonstrated go's "example tests" just yesterday to me and a group. He praised them highly for tech-adjacent fields where people don't have familiarity with software engineering practices for modular, tested, or ready to share projects. We discuss infrastructure, and it was enlightening to be reminded of the tech-adjacent fields that could benefit greatly from a few more of the practices common in the tech industry. I suppose the Joel test and 12 Factor app would be indicative guides.
- dougSF70 3y agoFor those interested: the meetup is at 7pm every Monday at noisebridge, 272 capp street, san francisco. It is always an evening well spent.
- dharmab 3y agoSome similar resources I like: "Learn Go with Tests" book: https://quii.gitbook.io/learn-go-with-tests https://quii.gitbook.io/learn-go-with-tests "Go by Example": https://gobyexample.com/ https://gobyexample.com/
- peter_l_downs 3y agoAgreed with most of this but I’m skeptical of the rsc.io/script dsl approach. I’ll try it, though, because Russ is often right. shameless advert: do you wish testify was implemented with generics and go-cmp, and had a more understandable surface area? Check out my small library, testy https://github.com/peterldowns/testy https://github.com/peterldowns/testy shameless advert: do you want to write tests against your postgres database, but each new test adds seconds to your test suite? Check out pgtestdb, the marginal cost of each test is measured in tens of milliseconds, and each test gets a unique and isolated postgres instance — with all your migrations applied. https://github.com/peterldowns/pgtestdb https://github.com/peterldowns/pgtestdb
- RSHEPP 3y agoJust helped a junior setup dockertest on a new service, interested in checking this out. Are you familiar with test containers or dockertest? How would you compare pgtestdb. We use postgres/pgx.
- peter_l_downs 3y agoGreat question! pgtestdb requires that you somehow run a postgres server. It then connects to that server and handles all of the database creation. The README goes into more detail here, but basically you should be easily able to point pgtestdb at a dockertest-managed postgres server. One massive advantage of pgtestdb compared to using dockertest on its own is that it handles running migrations for you in a very efficient way that amortizes the cost to zero as the number of tests trends to infinity. This should be much faster than naively creating a new database and re-running the migrations for each test. I happen to recommend using docker-compose over dockertest out of some slight personal preference that is one part separation of concerns (it's weird to me to have the test code handle the state of the postgres container), one part developer-experience related (it's nice for devs to be able to easily manage their postgres server instance with existing docker tools outside of golang code), one part infra related (it's nice to be able to use any method to provide and manage the postgres server, particularly in CI), and one part totally arbitrary.
- imran-iq 3y agoSee also Advanced Testing with Go by Mitchell Hashimoto[0] --- 0: https://www.youtube.com/watch?v=8hQG7QlcLBk https://www.youtube.com/watch?v=8hQG7QlcLBk
- rochak 3y agoMitchell is a legend
- ilrwbwrkhv 3y agoGo tests are fantastic. Fast, easy to write and just works. Another reason we moved to Go when moving off of Common Lisp.
- Xeoncross 3y agoAlso, writing benchmarks that report time, memory, and allocations is just as easy as writing a test. A huge win for Go compared to trying to accurately benchmark memory or cycles in TypeScript or Java.
- tylerneylon 3y agoI like the txtar file format mentioned in this video. (Described below.) I’ve worked with teams who would have rejected this idea from a junior dev because it might sound too simple. It’s easy to forget the inherent value of simplicity, which is at odds with impressive-sounding features, or demonstrating hard-won coding sophistication. This is the complete txtar file format: One or more comment lines followed by zero or more virtual files. Each virtual file begins with a line like “-- filename --“ and ends at the next such line. Specifically, these filename lines are those beginning with dash dash space and ending with space dash dash. That’s the whole format. It avoids the need to have multiple real files all over the place when you want just one real file but you want your code to think in terms of multiple files. (Eg have one txtar file that combines different blocks of test data.)
- chubot 3y agoWhat if you need to embed a txtar file in a txtar file? Formats without escaping eventually grow a bad version of it
- halostatue 3y agochezmoi (<https://chezmoi.io https://chezmoi.io> or <https://github.com/twpayne/chezmoi https://github.com/twpayne/chezmoi>) has a couple dozen txtar tests. They are both amazing and completely frustrating to use, but I don't think that there would be a better way to test most of what chezmoi does without them. Tom Payne (the creator and primary developer of chezmoi) has added some extra commands to the txtar context which makes things easier for certain classes of testing.
- nishs 3y agogo package: https://pkg.go.dev/golang.org/x/tools/txtar https://pkg.go.dev/golang.org/x/tools/txtar swift: https://github.com/littleroot/Txtar https://github.com/littleroot/Txtar
- devjam 3y agoA huge time-saver for me when adding table-driven test boilerplate in Go has been using gotests[0] to generate the template. If you use VSCode with the Go extension it's already available there as a command "Go: Generate Unit Tests for Function/Package". [0] https://github.com/cweill/gotests https://github.com/cweill/gotests
- kevinsundar 3y agoI just ask ChatGPT to do it. Actually just today I asked it to format an existing set of tests into table-driven format. Worked great.
- jimmyed 3y agoRuss Cox has fully imbibed his $DAYJOB into his life to the extent it feels unhealthy. Golang Shirt; multiple golang wall paintings; countless golang soft toys in the background and on his side. I am sure he has a few golang tattoos as well!
- nunez 3y agoHonestly if I were a founding engineer of a project like golang that's used all over the world, I'd be proud as shit about that too Also helps that he's probably getting stacks on stacks from GSUs
- tomcam 3y agoHow much enthusiasm do you recommend for a project of that magnitude?
- rsc 3y agoNo tattoos although maybe I should look into that.
- earthboundkid 3y agoI have a package that makes it easier to do the “use a glob of files as golden test cases” thing mentioned in the middle of the talk: https://pkg.go.dev/github.com/carlmjohnson/be@v0.23.2/testfile#Run https://pkg.go.dev/github.com/carlmjohnson/be@v0.23.2/testfi...
- manlobster 3y agoTest code doesn't have tests of its own, so we must rely on inspection to establish that it is correct. This means that test code must be extremely readable. It would make me uncomfortable to rely on tests like some of the examples in this talk, that have such a degree of complexity without explicit tests. Code such as to parse a text file should be in its own package. The package should expose an extremely readable API, and it should have its own suite of tests. Similarly, writing formatting code for error messages and diffs inline makes the tests less readable and therefore less reliable. The golang standard library should include testing helpers such as in `testify`, which would allow tests to be concise, less buggy, and extremely readable.
- deleted 3y ago[deleted]
- tptacek 3y agoIt's hard to do a lively presentation like this without an audience. I'm a little jealous of how well he does it.
- jeffrallen 3y agoI worked on a team with a metric and associated goal of x% code coverage. So of course, even negotiating what x should be resulted in a week's worth of meetings over a quarter. And the "branch coverage versus line coverage" war was long and ugly. When the metric was finally in place, it was of course immediately gamed to test getters and setters and to avoid the hard to test, sensitive integrated parts of the code. This, in the same organization where another team was told by it's VP, "don't schedule time for unit tests, we are too far behind schedule for a luxury like that". All this to say, #3 "coverage is not a substitute for thinking" really hit me in the (grumpy) feels.
- hknmtt 3y agoI do like Go tests. Would love to have ability to find out untested parts of the code base though to increase coverage, but I do not think there is a way to measure this with available tools just yet. Although I have yet to make integration tests that require live database and other dependencies. That will be fun... Anyway, my main gripe with tests or TDD is that even if the code base is 95% finished, not talking libraries here, even small code changes can cause a cascade of changes that need to be addressed and tests essentially multiply the work load by a factor of 10, easy. And I am not talking about big changes. It might be a simple addition of a new struct field which suddenly breaks half of your test suite. Hence teste should be, in my experience, written as the absolutely last step before going live. Otherwise they might impose massive costs on time, and potentially money(if we're talking actual business and not one man shot type of project).
- grose 3y agoYou can find which parts of the code are untested like this: go test -coverprofile=cover.out && go tool cover -html=cover.out
- mseepgood 3y agoYou obviously didn't watch the video, it explicitly demonstrates how to show code coverage.
- 5ersi 3y agoYou must be using a dynamic language with a heavy framework? Rails maybe? I code in Go mainly (also Java and Rust) and never experienced what you describe: simple addition of a field to a struct does nothing if not used in code. And the use is simply checked by compiler. However, I did work alongside a Rails team which had major gripes with this. They called it brittle tests: whenever they made a simple change (like adding a field), half of their tests would fail. This really lowered devs' confidence in their codebase and slowed the changes to a halt.
- randomdata 3y agoSmall code changes breaking a gamut of tests is indicative of testing the wrong thing. It is almost certain that you have tested the wrong thing if they start breaking on changes when you are 95% complete.
- ithkuil 3y agoLong time Go user, recently using rust as well. One of the things I miss most in rust are subtests and t.Errorf as opposed to t.Fatal. But perhaps I don't know how to do it. In most of the rust codebases I worked with tests contain sequences of asserts (the failure of which causes the whole test to fail). Procedural macros are often employed to create many smaller tests that seem to address the use case of table driven tests + t.Error or subtests. Macros in rust are ... adequate, but there is something bout being able to just express your logic in your main language instead of having to fiddle with a macro language and effectively code generation. Does anybody have good tips for bringing some of the enjoyable testing patterns from Go into Rust?
- randomdata 3y agoGo offering a delineation between "public" and "private" tests is also something sorrily lacking in other ecosystems.