I prefer to lean heavily on e2e/integration tests as much as possible, because I've found most bugs arise from the boundaries between discreet systems, particul

I prefer to lean heavily on e2e/integration tests as much as possible, because I've found most bugs arise from the boundaries between discreet systems, particularly when they are developed by different teams. However the point I was trying to make was more around super specific scenarios where a somewhat artificial test can highlight the possibility and prove that it's correctly implemented. As well as showing future readers that the code wasn't making an arbitrary decision but it was desired behaviour. For example it's difficult to simulate rare/transitive failure states in e2e testing, but unit tests you can easily force these, and verify that they are handled correctly. One thing that is tangential but springs to mind is when there are log statements that a monitoring system is observing - in these cases I'd add a unit test for that log line being emitted, not because I'm worried that the code doesn't work, but because I'm worried someone will remove it in future not realising that it was the backbone of some monitor