What coding practices do you follow? 🥷

🙋 Questions
,
1

Hi again,

I’m closing in on the end of my questions for our upcoming courses. The next question I had though was focused on coding practices within the context of writing automation code:

What coding practices do you follow?

In my mind this can range from ways of organising your code I.E. Page Objects, to more general development principles such as DRY and YAGNI.

I’d love to hear what formal, or informal, practises you and your team apply to your automation.

2 Likes
2

The Clean Code book was suggested for engineers, including QA automation engineers to follow at a previous employer.

1 Like
3

In terms of page objects, there are many areas where you can you can use different approaches to model the page objects as well, beyond just the general concept. I blog about some of them

4

Apart from the ones you mentioned, a few other practices I try to keep in mind are (many of these are directly inspired by Clean code book) :

  • Follow separation of concerns between code, config , data and test intentions. For example env configuration goes in cofig, test data is separated in data files and code is refactored into small methods whose names reveal the intentions. These Entity methods are then used inside tests.
  • Heavy emphasis on calling things as they are. Also to prefer Problem Domain based names over Technical Solutions based names where possible.
  • Use extensions (say from Junit5) to abstract away the common functionality across tests in a cleaner implementation.
  • Segregate actions that should be done at the run level from the ones that needs to be done at the class level from the ones that needs to be done at the test level. Use extensions again where possible.
  • Follow scouts rule to leave the test environment cleaner (or at least the same) than you found after test runs.
  • In context of code review, give references from credible sources while giving feedback on pull requests. For example, I would frequently embed snapshots from clean code book while giving feedback. This makes feedback easy to accept and absorb.
  • Prefer live test monitoring over snapshot test reporting to identify code areas that are flaky or stable over time.
  • Maintain a bias for keeping things simple, readable and maintainable.

There could be more things but these are the ones on top of my mind.

Cheers!