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
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
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.
Want to see if there's any speed improvements and better separation if we switch to pgtestdb. The transaction approach has worked well but on some larger integration tests I have seen some conflicts due to our test fixture ids.
The best I could come up with was to run MariaDB server with libeatmydata, which I believe was pretty much intended for this. It's not very "works on any MariaDB server"-generic, but it's good enough.
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).
go test -coverprofile=cover.out && go tool cover -html=cover.outI 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.
Junior or intermediate developers start writing code. Most functions manipulate internal state instead of acting cleanly on inputs/outputs. Writing tests for this style of code is hard, so developers reach for the nearest mocking library. Now, instead of testing that given inputs produce given outputs, tests are written in a way that effectively they only verify that functions are currently implemented the way they are currently implemented.
These style of tests literally have negative value (NB, not all mocking is bad, but these type of tests are). Delete them when you find them.
Testing should help you accomplish two things: find bugs and allow confident refactoring. These do neither.
They don’t help you find bugs because they don’t look for bugs. They look for “the code is currently implemented in a certain way”. And this of course means if you implement the same logic a different way, they will fail.
Negative value. Delete them, and whenever possible rewrite modules that are designed such that they need to be “tested” in this manner.
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.)
Formats without escaping eventually grow a bad version of it
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.
Also helps that he's probably getting stacks on stacks from GSUs
If you use VSCode with the Go extension it's already available there as a command "Go: Generate Unit Tests for Function/Package".
---
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?
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.
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 ;)
"Learn Go with Tests" book: https://quii.gitbook.io/learn-go-with-tests
"Go by Example": https://gobyexample.com/
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.