One of the things that happens in new Selenium automation projects is that the focus is initially only on writing code that works. Writing more Selenium tests, more page classes, more page methods.
And, in time, the project grows, test classes grow, page classes and page methods as well.
And this is a problem.
Anything that is too big is difficult to work with. Difficult to understand, difficult to maintain, difficult to change and difficult to read.
So we should keep everything small. Smaller classes are better than bigger ones, smaller methods are better than bigger methods, etc.
Smaller is better than bigger.
But what does smaller mean?
Is there a definition for it?
Yes, the rule of 30.
If an element consists of more than 30 sub-elements, it is highly probable that there is a serious problem:
a) Methods should not have more than an average of 30 code lines (not counting line spaces and comments).
b) A class should contain an average of less than 30 methods, resulting in up to 900 lines of code.
c) A package shouldn’t contain more than 30 classes, thus comprising up to 27,000 code lines.
d) Subsystems with more than 30 packages should be avoided. Such a subsystem would count up to 900 classes with up to 810,000 lines of code.
Next time you create a new class or method, please keep it under 30 methods and 30 lines of code.