Separation of writing unit tests in a team

Question

Software testing

Hello. I work in a fairly large company on a project being developed by 12 programmers. The project is quite large (more than 20 maven modules) and its main problem is the almost complete lack of unit tests (there are 300 tests, but almost all of them are at the integration level and of poor quality). The team leader and the company understand that the presence of tests is a good and necessary thing, but at the moment they do not want to introduce the mandatory writing of unit tests by each developer (almost none of them had experience writing tests, plus the time frame is too tight to allow a "permeated" project developers, to spend time NOT on writing new features).

Now, we are trying to write separate unit tests. Developer1 (tester) and developer2 (implementer) receive a detailed functional specification (use-cases, description of business logic, etc.), the tester is responsible for writing tests, the implementer, respectively, writes the implementation of the tests.

This approach entails many different disadvantages (for example, the tester does not receive feedback from writing code, the tester may misunderstand the user cases and thus write the wrong test, the implementer without the tester may write non-testing-friendly code, etc. ).

The main thing that the authorities demand is to allow developer1 to write only the implementation and developer2 only to write tests.

Q: Has anyone in their organization experienced anything similar? What problems did you encounter and how were they solved?

Answer 1

Poor, poor test implementer... programmers nah-code due to "hard time limits" and he will try to figure it out, not to mention that programmers may simply not create a minimal API for implementing tests. The one who writes the code should write the tests, because he knows it best of all and can always refactor it so that the tests can be written at all.
You need to start at least by writing tests for the code that you just wrote, and gradually for what has already been written. Anyone who understands why tests are needed writes them without reminders, because he knows that one or two days spent on writing tests will replace weeks of debugging, including helping to find such errors that can be found in a month or more of use in production. But it’s hard to understand if you haven’t gone through it yourself (I was like that too). At first they forced me - and I wrote them. Now I can't imagine how you can write code without tests, for me this is a necessary margin of safety.
The speed of writing tests is also affected by the framework, so learning to use it also plays a significant role.