Speaking code do a good job as long as we need to share and improve knoweledge about the domain.
Otherwise an alternative “legitimate” option is to pick up already existing code, no matter if it doesn’t “speak”.

It’s interesting to note that in Domain Driven Design tests are useful tools not only to validate application behavior, but also to validate code readability. A common DDD practice is to start an exploratory coding session writing tests with no attention to the existing code: the idea is to “Write the code that you would like to have”, in a language that is clearly readable by developers and domain experts. Put in this way …assertions might be optional (and thus the word “test” would be misleading). We’re basically testing the expressiveness of the code.
Making the code actually work is a different job. Sometimes it’s easily achievable, sometimes it’s harder. But decoupling from the existing code is often necessary to get closer to the domain.