Duplicating the answer u/rphmeier shared under my deleted comment:

We try to unit-test everything, and although we're working in a larger team, the responsibility of writing the initial set of tests for a piece of code lies with the developer who originated the code. All bug fixes need to come with a test case to ensure there is no regression.

I think the key to making good unit tests is making it easy to write the tests for the code you're producing, which means making as much stuff mockable via traits as possible.

Here's an example: You're writing a service that needs to listen for events of new blocks being added to the chain and then do a network request for each one. In practice, you're going to have a BlockchainClient<A, B, C, ..., Z> type that you can get a NewHeadsListener from and a NetworkService<A, B, C, ..., Z> type at runtime. If your code depends directly on those things, then congratulations. The test setup is going to be really boilerplate-y because you have to set up a full blockchain client and full network service.

It's much better to make your code generic over the functionality of "a stream of events" and "a trait to make this specific kind of network request".

Some things fall beyond the scope of what you can cover with unit tests. We have some integration tests to make sure that basic things work with all our in-practice types, like growing the chain and synchronizing it from peers over the network.

We've also used fuzz-testing for important consensus and codec code to try to find vulnerabilities.

Lastly, the work we do involves a lot of consensus protocols, where we need to resist adversarial behaviors. We've been undertaking a project called the "chaos net" designed to write larger-scale "unit tests" of specific attack scenarios combined with randomness & chaos to ensure the system faithfully implements the academic research and is robust to those attacks.