true == true
"Programs should be written for people to read, and only incidentally for machines to execute".
-- "Structure and Interpretation of Computer Programs" by Abelson and Sussman
UI automation code is just another piece of "code" hence all the code best practices applies in the same way.
If I have to pick one thing, I would say code shouldn't read like code, it should read like a natural language in the business domain(DSL) on higher layers(test scripts/page object public methods in the automation framework).
All the statements inside a function should be on the same level of abstraction.
class AddAttendeePage def add_attendee_with_details fill_in('user_email',with:'[email protected]') fill_in('user_first_name', with: 'test') fill_in('user_last_name', with: 'test') fill_order_form click_add_attendee end def fill_order_form # ... end def click_add_attendee # ... end end
The add_attendee_with_details method here brakes the rule.
fill_in(‘order_user_email’, :with => ‘[email protected]’) part is more detailed than the
fill_order_form part, so the code inside the
add_attendee_with_details written on a different level of abstraction.
All the basic 'code' semantics(loops/if/switch) should be deeply buried in the lowest layers of the framework.
If NOT, these are one of most obvious code smells to me that code is not structured properly in different layers in the framework which makes code maintenance a hell due to multiple reasons on multiple levels in the long term.
The area to cover in code reviews deserves a book chapter if not multiple books. First, let's not forget test automation is no different from other branches of software engineering, so let me quote generic suggestions from Gergely Orosz (emphasis mine):
Good code reviews look at the change itself and how it fits into the codebase. They will look through the clarity of the title and description and “why” of the change. They cover the correctness of the code, test coverage, functionality changes, and confirm that they follow the coding guides and best practices. They will point out obvious improvements, such as hard to understand code, unclear names, commented out code, untested code, or unhandled edge cases. They will also note when too many changes are crammed into one review, and suggest keeping code changes single-purposed or breaking the change into more focused parts.
Better code reviews look at the change in the context of the larger system, as well as check that changes are easy to maintain. They might ask questions about the necessity of the change or how it impacts other parts of the system. They look at abstractions introduced and how these fit into the existing software architecture. They note maintainability observations, such as complex logic that could be simplified, improving test structure, removing duplications, and other possible improvements. Engineer Joel Kemp describes great code reviews as a contextual pass following an initial, light pass.
Then there are things that are specific to test automation. Code reviews should specifically point out:
I would need to quote whole SQA Stackexchange to make this answer complete.
Finally, let's not forget code reviews play education roles. It's a great way to make new team members aware of code guidelines specific to the team and the project. It's also a great opportunity to teach programming to junior programmers (which often happens in test automation teams).