I agree with Oscar, and I'd like to add a point: one could argue that spliting a large codebase into several smaller ones could actually benefit the team, and for that I'd say: be aware that you will end up with more "moving pieces", so it might be a bit of a trap: trading coding complexity for operational complexity.
One other thing: presuming this code has little to no coverage, I would first aim at integration tests rather than unit tests - test bigger chunks first, making sure that bigger flows are actually understood (and at the time building a sort of documentation for this code), and then moving in to unit testing smaller pieces.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with Oscar, and I'd like to add a point: one could argue that spliting a large codebase into several smaller ones could actually benefit the team, and for that I'd say: be aware that you will end up with more "moving pieces", so it might be a bit of a trap: trading coding complexity for operational complexity.
One other thing: presuming this code has little to no coverage, I would first aim at integration tests rather than unit tests - test bigger chunks first, making sure that bigger flows are actually understood (and at the time building a sort of documentation for this code), and then moving in to unit testing smaller pieces.