POM: Page object Model:
Arrange the page related actions in respecive classes eg: all login page actions,elements etc in the loginPage class. This helps in easy maintainability and DRY code.
The Page Object Design Pattern provides the following advantages:
There is a clean separation between test code and page specific code
such as locators (or their use if you’re using a UI Map) and layout.
There is a single repository for the services or operations offered by
the page rather than having these services scattered throughout the
Don’t Repeat Yourself (DRY) is a software development principle, the main aim of which is to reduce repetition of code
So page object ensures that your code follows DRY code principle.
Avoid proliferation of classes
This is a case that caused by creating unnecessary classes that inturn causes maintainance heading. You don't want to make your framework to look complicated just to make others think its a engineering marvel.
Engineering design marvel is to create something simple to use but highly functional , so focus on your scope of testing and the users , than how to make it complicated
Eg: don't need to add elements in a separate class , and then call it in page object , and then abstract it with higher level keywords etc when you really don't have to . But if it makes the life of people who uses it easier, then don't hesitate also.
KISS (Keep It Simple Stupid)
When a program grows in size, the complexity of the code tends to
increase. This would give you a hard time debugging, as debugging
complex code is a gruesome task. Nobody loves to maintain complex
code. This principle states that you should always keep your code
simple. If you have a complex piece of code, always try to break it
into smaller more maintainable code.
Ensure proper html reporting
Your framework should have proper reporting, this will help in easy debugging. IT should have screenshots and stack trace.
THere is no need for special logger , you can just redirect error and output to a text file .
Promote data driven testing
This is a continuation of DRY principle, you can use the same code to test different scenario using data drivern approach without writing any additional code . THis allows helps in additional coverage.
Simple project structure
pageobjects : page object classes
testscripts : ACtual automation test cases
reports : Folder where report is generated
datafile : File for data driven testing , files like drivers etc
in some frameworks you need to override listner classes to create report so in that case you can create a separate folder:
listners : listner classes
Thats it , you are ready to go