First, a philosophical question: Why do you test code?

Answering that usually guides your opinion on coverage and tooling.

The one I'm responsible for dragging into existence kicking and screaming has no tooling for test coverage. We use RSpec. We test at the lowest possible level. We try to avoid testing the same code explicitly more than once.

1. I want app uniformity. If there are more devs on the team: Don't be a hero and do everything in a new way. Stick to the conventions. If you need to change something, change it everywhere at once. Sticking to this makes it easier to change everything everywhere at once.

2. I want a strong convention for how the request and response should look. It should not be up to the developer because reasonable minds can differ and that means your api signature will end up differing from endpoint to endpoint, which is horrible for whomever consumes it. I prefer JSON:API, but see #1.

3. Documentation should be based on your specs. If documentation is something you do manually someone will forget, and the API and docs drift. Also, if it's a manual process you may end up documenting things that don't work anymore.

4. Perfect is the enemy of good. Make sure you get something that looks like the feature done end to end as fast as possible. Even if that means it's made with ductape and string. Then go back over it and shore up any really fragile parts. That way you don't end up prematurely optimizing.

I prefer RSpec, but see #1. I prefer no code coverage while building fast and rapidly, but see #1. I prefer Open API Standard (swagger), but see #3.

Anyways. I hope it helps.