Hello Enrique, it is a bit disappointing to me if you point me to a lot of articles which are not suitable for my arguments.
You mention Selenium articles. They assume that tests are written as JUnit tests. They do not assume that JBehave or BDD is used instead. The arguments in the Selenium articles apply if you use something like JUnit to write tests. But they don't apply for JBehave in my eyes. These articles mention these reasons for having page objects: * Reduces the duplication of code * Makes tests more readable and robust * Improves the maintainability of tests, particularly when there is frequent change in the AUT. (Useful in Agile methodology based projects) * There is no separation between the test method and the AUTs locators * The id-locators would be spread in multiple tests All this can be achieved by using JBehave steps, provided they are abstract enough (not a too fine granularity of steps). I bet you will now point me to read some books instead of arguing against my arguments ... 2013/9/19 Jorge Pombar <[email protected]> > Hi Hans,**** > > I believe I provided links to articles that explained the reasons why we > like PageObjects. I would be repeating the same arguments (probably in > worst English) that they did. Once again is design is very subjective and > as you pointed out there is more than 1 right answer.**** > > ** ** > > Thanks,**** > > Enrique**** > > ** ** > > *From:* Hans Schwäbli [mailto:[email protected]] > *Sent:* Thursday, September 19, 2013 5:02 AM > > *To:* [email protected] > *Subject:* Re: [jbehave-user] Do I really need Page Objects?**** > > ** ** > > Hi Enrique,**** > > **** > > I wrote concrete arguments against using page objects together with > JBehave since I think they are redundant when using the steps of JBehave. I > wished you would explain why you think that my arguments are not valid in > your case.**** > > **** > > It does not help me if you say "PageObjects have worked the best". This > statement is very general and explains not why my objections don't apply in > your case.**** > > **** > > The only advantage I see in using Page Objects with JBehave is to be more > independant of JBehave. But the price is redundancy and an additional (not > required) layer to maintain and higher code complexity.**** > > > In ealier times (and often today) GUI tests with Selenium were written > with JUnit. Page Objects or something like it was required then. But with > JBehave you already have to write steps (which is "something like it"). So > why do you think page objects are not redundant then? Where do you see the > benefit of writing Page Objects for JBehave tests if you already > have JBehave steps which contain the logic to do business logic on the > screen?**** > > **** > > Please explain it to me, I am very curious.**** > > **** > > > **** > > 2013/9/18 Jorge Pombar <[email protected]>**** > > Hi Hans,**** > > As you said “[Page Objects] is one way to achieve this, but not the only > one”. For us PageObjects have worked the best but that might not be the > case for you. Let me leave you with some of the articles that I read when > coming up with our design.**** > > **** > > > http://docs.seleniumhq.org/docs/06_test_design_considerations.jsp#page-object-design-pattern > **** > > http://code.google.com/p/selenium/wiki/PageObjects**** > > http://code.google.com/p/selenium/wiki/PageFactory**** > > http://code.google.com/p/selenium/wiki/LoadableComponent**** > > http://assertselenium.com/automation-design-practices/page-object-pattern/ > **** > > **** > > Happy JBehaving J**** > > Enrique**** > > **** > > *From:* Hans Schwäbli [mailto:[email protected]] > *Sent:* Monday, September 16, 2013 11:20 PM**** > > > *To:* [email protected] > *Subject:* Re: [jbehave-user] Do I really need Page Objects?**** > > **** > > Hello Enrique,**** > > doesn't JBehave steps provide already maintainability? I still don't see > why I would need page objects when using JBehave.**** > > If GUI changes, then the steps implementation can be changed. It is a > single point to maintain if steps granularity is not too fine. The steps > can take care of the browser interaction. The steps stay the same then, > only their implementation changes if GUI changes.**** > > Why should I use additional page objects for that? I don't see the > advantage for maintainability. Page objects could make it easier to replace > JBehave, but that is the only advantage I see.**** > > Besides that, why should I re-model the GUI with page objects for the sake > of maintainability? This is one way to achieve this, but not the only one. > Any modularization will achieve this. And one way of modularization are > step methods, provided they have not a too fine granularity.**** > > I feel that using steps I am not so dependent on GUI changes compared to > using page objects. For instance, if the login stretches across two pages > and they change that to a single login page, I would have to re-model and > refactor the page objects. But if I use a step method like "login(user, > password, extraInfo)", the only thing I would need to update is the method > implementation of the step.**** > > JBehave is already a test framework to me. I may write a little framework > around it in order to customize it, but no more.**** > > These are my thoughts to your objection.**** > > **** > > 2013/9/16 Jorge Pombar <[email protected]>**** > > Hi Hans,**** > > I have a different take. In my opinion PageObjects are a must if you are > writing any test framework for any WebApp**** > > The #1 reason is maintainability. WebApps by their nature change their GUI > a lot. By calling a pageObject in your step and letting the pageObject take > care of the browser interaction then you have a single point to maintain > when something changes on that page.**** > > **** > > This way your steps stay the same while you only change the pageObject > when something changes on the page. Anyways, just my 2 cents. This is the > way we have implemented it (and the recommended design pattern) and it > works very well for us.**** > > **** > > Thanks,**** > > Enrique**** > > **** > > *From:* Hans Schwäbli [mailto:[email protected]] > *Sent:* Monday, September 16, 2013 9:20 AM > *To:* [email protected] > *Subject:* Re: [jbehave-user] Do I really need Page Objects?**** > > **** > > Thank you for your answer.**** > > **** > > By the way, I didn't want to compare JUnit and JBehave but intended to > compare JUnit + Page Objects on one side with JBehave + Steps on the other > side.**** > > **** > > I think I won't use page objects since JBehave has steps. There is no need > to write tests with JUnit side by side with JBehave. And I don't intend to > be more independent of JBehave by having a page object layer.**** > > **** > > Then I will see later if I really don't need page objects (but now I > really think so).**** > > **** > > 2013/9/16 Mauro Talevi <[email protected]>**** > > Hi Hans, > > the short answer is no, you don't need to use page objects if you don't > feel the need for them. > > Page objects are a design paradigm that enable you to encapsulate the > access to the business functionality exposed by the given web page and make > it easier to maintain it, while possibly changing the underlying > interaction, which can be at times rather complicated (web-speak and all). > > The re-usability and readability criteria that you mention apply equally > to JBehave and BDD as they do the JUnit and unit testing. Even more so, I > would argue. E.g. they can be re-used across multiple steps classes. > > It is true though that page objects introduce another layer between steps > and testing API, and it's up to you to decide if they are an advantage or a > hindrance. You can also introduce them when they are needed and start > off without them. > > Cheers**** > > > > On 16/09/2013 15:45, Hans Schwäbli wrote:**** > > I started to write JBehave stories and steps and also page objects. Some > examples of JBehave contain page objects, so I thought this is a good idea. > But now I ask myself what advantage there is if I write page objects? The > steps which I write are re-usable and I can structure them in a similiar > way like page objects (per page for instance). > Even today some people use JUnit for running GUI tests. I understand that > you need page objects with JUnit, because of re-usability and readability. > But JBehave has its steps which are re-usable and readable, so why should > I write page objects addionally? I see no advantage but more effort. > Did I overlook something? What would the disadvantage be of not using page > objects with JBehave?**** > > **** > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email**** > > **** > > **** > > ** ** >
