My main rule of thumb regarding this is the following:
- Do automation in the same technology as the target.
- Avoid Domain Specific Language (DSL) for the automation.
- Collocate the automation code and the target code in the same repository.
If you can use the same language you have a lot more people that can do it which reduces the chance of your automation being a bottleneck or obsoleted (due to lack of throughput).
And if it is in the same repository it makes it easier to keep automation up to date with current development.
Then the few exceptions to these rules. Some tools are to good to not use even if they do not match your technology.
Some problems are to superior to solve with specific languages or you already have the knowledge for the other technology so you do not need to use the same technology.
To the last rule I have no exception (apart for sub optimal ones like political reasons like “testers are not allowed to work in the developer repositories” etc). But if you want to have the idea that you want an different part to create the test coverage than creating the code itself then I would suggest you have a look at Contract Driven testing and tools like https://docs.pact.io/.
If you are developing a service with an API, you have a part of your repository that contains the contract tests. That is maintained by the consumers of your service. So when you change, build and test your service you check that the contract aka what the consumers need still works. There are a few tools that can help with this setup and pact is one of them.