No Encapsulation in my project



  • 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.



  • 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.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2