The anatomy of a good unit test
A good test has one behaviour, a business-intent name, and assertions about behaviour rather than implementation.
A good test has a recognisable shape, and the shape is worth being strict about.
It has three movements: arrange (set up the situation), act (perform the one behaviour under test), assert (state what must now be true). One behaviour per test — if you’re testing two things, write two tests.
Its name states business intent, not mechanics. rejects_invite_when_no_seats_remain tells you what the system promises. test_invite_2 tells you nothing and rots immediately.
And — the most important and most violated rule — it tests behaviour, not implementation. A good test asserts what the system does, the promise a user or another part of the system relies on. A bad test asserts how it currently does it, reaching into internals. The bad kind breaks every time you refactor, even when nothing’s actually wrong, which trains everyone to ignore the test suite. Test the promise, not the plumbing.