Given i\'m building my angularjs protractor e2e tesing suite leveraging the page objects pattern.
And i separate page object code in different files as much as reasonabl
Here is link to a tutorial I set up for training some of my co-workers on create good Protractor test suites.
It's all live, with a demo site that you can visit, explore, etc.
https://github.com/Droogans/ProtractorPageObjects
This will set you up with installation, outlines, organizational techniques, and more.
Feel free to leave an issue if you have any trouble.
My opinions and how we structure our test...
One general page model that holds some methods we expect most pages to use like go()
or we have methods for interacting with some common custom elements.
Many page-specific models that inherit from this general page. Most of the methods on these models are related to getting various elements on the page or interacting with that page's ui. There are no assertion methods on these models.
UI models for interacting with certain more complicated widgets. Similar to page models but these aren't tied to a page. They are tied to a UI/widget. There are no assertion methods on these models.
For common & reusable assertions, we have assertion models that utilize various page models' and UI models' interaction methods. They are organized by page or UI. For assertions that are uncommon and not really reusable, we just put them into the spec itself.
Specs are usually organized by page though we do have specs for certain UI/widgets.