You probably know who Martin Fowler is.

He coined the term Page Object Model sometime in 2013:
https://martinfowler.com/bliki/PageObject.html

Yes, the page object model that you use in your Selenium test automation projects.

His contribution to software development goes way beyond the page object model since he wrote many useful books on topics such as code refactoring and design patterns.

He also said that

Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.

This is what I want to focus on today, on the code written by good programmers.

Good programmers write code that other programmers can understand but also can change and maintain.

This is what we should aim at in our Selenium projects.

Our code should also be easy to understand, change and maintain.

 

How do you know if your code does all these?

What are the rules that your code should follow so that it is good?

Let’s see.

 

Write Clean Code

The code should be clean.

This means a lot of things.

1. The code should use clear names

Variables should have names that explain their purpose.
Methods should have names that either explain what the method does or the result returned by the method.

2. Use problem domain names

If you do automation for an e-commerce site, make sure that you have classes for concepts such as

• product
• user
• basket
• cart
• order
• invoice

3. Classes should be small

A class should contain an average of less than 30 methods.

4. Methods should be small

Methods should not have more than an average of 30 code lines.

5. Do one Thing

This applies to both classes and methods.
If a method does more than one thing, consider splitting it in 2.
If a class has more than one responsibility, consider breaking it in more classes.

6. Don’t Repeat Yourself 

Any duplication, inside a page object class, a page method, a test class or a test method should be avoided.

7. Explain yourself in code

Write code that is self-explanatory, that is so easy to understand so no comments are needed.

8. Make sure the code formatting is applied

Code formatted correctly is easier to read by other developers.

9. Use Exceptions rather than Return codes

If a method cannot fulfill its purpose, instead of returning an obscure error code,
throw an exception since the code is in an abnormal state.

10. Don’t return Null

There are many ways of avoiding returning null.
You can use Optional introduced in Java 8.
Or you can return an empty list.

Write Secure Code

1. Make class final if not being used for inheritance

Making the class final ensures that it is not extended.

All page classes and page element classes should be final.

2. Avoid duplication of code

3. Limit the accessibility of packages,classes, interfaces, methods, and fields

Parent classes (base page class, base test class) should be abstract.

All methods of a parent class should be declared as protected since they should only be used in the child classes.

Only a small number of methods of any class should be public.

If a class should be used only by other classes in the same package, use the default access modifier.

4. Validate inputs (for valid data, size, range, boundary conditions, etc)

Any public method should have its parameters checked for validity.

5. Avoid excessive logs

If you are logging tracing information for all page classes and their methods, when you run the whole suite of tests, you will get excessive logs that are very difficult to read.

This becomes even worse if the automated tests are run in parallel on different virtual machines.

6. Release resources (Streams, Connections, etc) in all cases

Consider using try/catch with releasing resources.

7. Purge sensitive information from exceptions (exposing file path, internals of the system, configuration)

8. Do not log highly sensitive information

9. Make public static fields final (to avoid caller changing the value)

10. Avoid exposing constructors of sensitive classes

Use a factory method instead of the constructor to create objects.

General Rules

1. Use checked exceptions for recoverable conditions and runtime exceptions for programming errors

2. Favor the use of standard exceptions

3. Don’t ignore exceptions

4. Check parameters for validity

5. Return empty arrays or collections, not nulls

6. Minimize the accessibility of classes and members

7. In public classes, use accessor methods, not public fields

All fields of a class should be private so that objects cannot be changed (stay imutable).
Set methods are bad for the same reason since they make an object mutable.

Get methods should be used to expose fields outside of the class.

8. Minimize the scope of local variables

Declare the variable just before you need it and not at the beginning of the method.

9. Refer to objects by their interfaces

Also called program to an interface.

10. Adhere to generally accepted naming conventions

11. Use enums instead of int constants

SortOrder.PriceAscending is always more clear than 1.

12. Beware the performance of string concatenation

Use StringBuilder class instead.

13. Avoid creating unnecessary objects

 

This is obviously an incomplete list.

But it should get you started on focusing more on the quality of your code.

Because, good programmers write good code and you want to be a good programmer.

Don’t you?