I don't think there is a universally agreed-upon set of best practices.

In my experience, the very best practice is to create at least one library file per website page (see page object library for our implementation). I rarely use .robot files for keywords, almost everything my team does is to create keywords in python. I've worked at four different companies that used robot, and the one that took this approach has been the most successful.

You write "one __init__ file per tests file", which I don't understand. You can put an __init__ file in a directory, but I don't know how you can associate an __init__ file with a test file. I do not like using __init__ files inside of folders; in my experience they make it slightly harder to run individual suites.

As for organizing tests, one file per page is a good starting point. In my experience, comprehensive suites may need to be split into more than one file per page. For example, one app that I work with uses one suite just for the left navigation on the page, another that is specifically for the header and footer, and another for the main area. The main area can have multiple sections (we call "panels"), each of which has a set of tests in its own file.

I don't think there is a universally agreed-upon set of best practices.

In my experience, the very best practice is to create at least one library file per website page (see page object library for one such implementation). I rarely use .robot files for keywords, almost everything my team does is to create keywords in python. I've worked at four different companies that used robot, and the one that took this approach has been the most successful.

You write "one __init__ file per tests file", which I don't understand. You can put an __init__ file in a directory, but I don't know how you can associate an __init__ file with a test file. I do not like using __init__ files inside of folders; in my experience they make it slightly harder to run individual suites.

As for organizing tests, one file per page is a good starting point. In my experience, comprehensive suites may need to be split into more than one file per page. For example, one app that I work with uses one suite just for the left navigation on the page, another that is specifically for the header and footer, and another for the main area. The main area can have multiple sections (we call "panels"), each of which has a set of tests in its own file.