Structure of page object-based test projects

Question

Are there techniques and/or best practices to create and manage the structure of page object-based test projects? I'm not concerned about the implementation of the page objects, but rather how to organize the entire project.

Suppose I have a separate Java/Maven test project for some type of SUT (not necessarily a web application), how should I structure page objects, tests, resources, … ?

Something like:

src
|-- main
    |-- pages
        |-- login
            |-- main
            |-- preferences
            |-- ...
|-- test
    |-- pages
        |-- login
            |-- ...

Answer 1

I used pretty much the same structure, however it was still a bit different. Since Page Object pattern is more about "page objects" rather than the pages as they are known by the most of the web users, there could be the objects which do not relate to any particular page. For example the fragments which might appear on every page (like footer or header sections) or "objects" which the user can "invoke" on quite a lot of the pages because of the design pattern reusage.

Thus I had the following structure under the main:

src
|-- main
    |-- elements
        |-- ...
    |-- common
        |-- header
            |-- ...
        |-- footer
            |-- ...
    |-- pages
        |-- login
            |-- main
            |-- preferences
            |-- ...

Where elements contains the objects representing the complex controls which are widely used on the UI, common contains the areas which are common for all the pages, and pages contain the "fragments" which have some specific functional value for a user.

The structure under test was a bit different as well. Since I didn't want to accosiate the design pattern of the tests with the design pattern of the main code. I could afford this (without missing the common sense) also because my tests worked with the e2e user flows rather than single and atomic user actions like just "login" or so.