I'm familiar with the Page Object Pattern from doing Selenium tests. It seems to me like the Angular 2 team has borrowed this concept in their testing documentation.

But I feel like this is not precisely the same concept. In Selenium tests, the Page Object quite literally represents an entire HTML page. In the Angular 2 docs, it only represents a single component that would be used on a page.

What are the tradeoffs behind naming something based on a historical concept that the thing is drawn from vs. naming it based more exactly on the current concept? I can see where naming it "Page" would make it more accessible to people who had previously worked in Selenium, but it seems like it might be harder for new people to understand it as a Page when it's not really a Page.

Edit based on feedback

I think that there are often cases where something could be named according to a legacy convention or using a fresh name that more exactly matches the way the concept will be used moving forward, so I don't think that there's that big a need for background information in an answer.

I've actually been on a project where I rewrote an older framework and tried to keep concepts and variables as close to the older framework as possible to make it accessible to the people who had worked on that framework previously. But it was several years before anyone from that team used the newer framework and they worked on different projects than I did so I didn't get much feedback on whether that helped them. In this case, there may or may not be overlap between people familiar with the Page concept and most Angular 2 developers.

Assume that this is based on someone starting a new Angular 2 project that may add developers later. The future maintainers may not have Selenium experience, and the original developer is trying to decide whether to follow the "Page" convention from the documentation or call it something more close to the actual concept, like "Component," or even "ComponentPage," to pay homage to the older pattern while updating it.

What factors would come into play in deciding whether to just straight up follow the current docs vs. striking out in a way that makes more sense in isolation? I feel like I'm probably not the only person who's ever going to notice this, so there's a possibility that the docs could be updated if the "right" person points it out. OTOH there's a lot of counterintuitive stuff in popular Angular style guides that don't make sense in really large projects IMO so that might not be a large risk.

  • Whoever down voted, would you mind providing feedback so I can improve the question? Dec 7 '16 at 17:50
  • Incredibly broad question. Any decent answer would have to establish an enormous amount of background material to be useful to others. Also, "naming things is hard." Dec 7 '16 at 18:18
  • There's only one significant factor that I am aware of: clarity. Which naming convention would be clearer? Dec 8 '16 at 2:05
  • I guess that depends on whether you mean "clarity in a vacuum" (absolute clarity) or "clarity in context" (how it aligns or doesn't with the docs/community best practice). In an ideal world, those two things would be the same. In the real world, not so much. Dec 8 '16 at 18:34

Your Answer

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

Browse other questions tagged or ask your own question.