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.