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).
It is easier to find people who knows JavaScript, Java, C#, Python etc than knows a specific DSL for a tool.
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.
To me codeless tools, in general, is a new layer / new generation of the IT stack. See for instance The next-generation app platform | Airtable that is both a database and a spreadsheet handled not by scripts but by clicks. Codeless automation tools are a part of this trend, as with see with numerous test tools.
1 thing Pro:
If a consultant can automate her unique process into a tool in hours, she can solve customer’s problem faster and show the value of her efforts. If a small business owner can build an app for his needs, he can increase business efficiency with automation and save valuable time to expand his business.
From No-code Revolution. Why Now?
I have used some of these new(est) generation tools when either the codebase was unavailable to add testability into (license issues etc) or so old that you need the power of the higher order tools to even add automation in the first place. Just last week discussing how to even get started doing test automation on a mainframe that was built in the 70’es - it has no API, only the GUI.