1

It's been a long time that I am writing Test Automation scripts in Java, but I never had encapsulation in my code (code hiding).

Creating Interface, Abstract Classes or Java beans were never part of my code and I never faced any issue without them. However, when I see the code of other Test Automation Developers I see a lot of encapsulation and it makes me think that I am less skilled developer than them.

Question is: Not having encapsulation, is it a bad practice? If No/Yes, how to identify the need for encapsulation? So that sometimes if someone reviews my code I could debate that your logic doesn't fulfill the criterion of having an encapsulation.

2

OOP concepts like encapsulation could make your life easier. Probably they help when multiple programmers work on the same code-base. If you are alone you might work in a single file, but as complexity and contributors grow it might make sense to apply good OOP principles.

The term encapsulation is often used interchangeably with information hiding.

In computer science, information hiding is the principle of segregation of the design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modification if the design decision is changed. The protection involves providing a stable interface which protects the remainder of the program from the implementation (the details that are most likely to change).

https://en.wikipedia.org/wiki/Information_hiding

The pageObjects pattern is a form of encapsulation. Which is very common as a test-strategy concept for UI based end-to-end tests.

Page objects are a classic example of encapsulation - they hide the details of the UI structure and widgetry from other components (the tests). It's a good design principle to look for situations like this as you develop - ask yourself "how can I hide some details from the rest of the software?" As with any encapsulation this yields two benefits. I've already stressed that by confining logic that manipulates the UI to a single place you can modify it there without affecting other components in the system. A consequential benefit is that it makes the client (test) code easier to understand because the logic there is about the intention of the test and not cluttered by UI details.

https://martinfowler.com/bliki/PageObject.html

For the rest I think the answer to your question is it depends. It depends on the scale and complexity if your test-code, the number of developers and what works for you and your team.

| improve this answer | |
  • Certainly, OOPS makes life easier, but encapsulation also does same, can you quote an example? Changing the implementation effects across the project but not interface, how come? We work in Test Automation team using PageFactory, PageObject Patten, Singleton design pattern – paul May 19 '19 at 2:25
  • Encapsulation is part of OOP, and pageObjects is Encapsulation. What more examples do you need? I think you should read up on it and practise in test projects, because I think you are confusing concepts. – Niels van Reijmersdal May 19 '19 at 4:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.