Automated testing is the process of writing code to understand your code. We already have to understand our code. Testing is being deliberate about that understanding and writing it down. The same design/testing thoughts that lead us to edge cases can lead us their elimination without testing at all. It's an integrated process, not something separate.
Tests are documentation of code behavior. Who better to document that behavior than the person that wrote it in the first place.
> It's an integrated process, not something separate.
I agree. Though I'm biased since I've mostly been in SET roles.
Developers should also write their own tests. QA should have tests too. It shouldn't be a matter of throwing software over the fence to a separate group.
That said, it's often possible to write higher level tests in advance as a specification, or afterwards as a regression/integration suite. Testing code can be used for many things such as UI regression testing, performance testing etc. That kind of test is black box and not tied to a specific piece of code.
So I think it's hard to debate "who tests" or "who writes tests" without discussing exactly what kind of test.
For unit tests that's pretty much the norm, and you could easily split those up between two developers. One writes the tests for the code of the other and vv.
Integration tests tend to be written by a test engineer, sometimes doubling as QA.
Team size is a big factor in these decisions, one solution does not fit everybody.
I think that's a misunderstanding of the use of unit tests. Devs should be writing unit tests so that I can write more interesting tests that assess quality (which is not what unit tests are for).
And then there's the real world, where my agenda today consists of...writing unit tests for code I didn't write.