Hello Enrique, no problem, but I don't understand why you don't provide arguments as I have done. You seem to be easily offended by just one ironic sentence.
I intended a productive discussion with you, no quarrel. This requires arguments to be exchanged and an open mind. I have such an open mind, but I cannot just follow an opinion when I provide arguments against its validness. Maybe there is someone else out there who can explain me, why page objects make sense when someone is already using JBehave steps. 2013/9/23 Jorge Pombar <[email protected]> > Hello Hans,**** > > “I bet you will now point me to read some books instead of arguing > against my arguments”**** > > That’s the key point to me. You are looking for an argument and I’m not. > My purpose was just to offer my 2 cent in case it helped you or someone > else. It looks like my 2 cents won’t help you and that’s ok. **** > > ** ** > > I won’t reply to this thread anymore as I don’t have anything else to add. > I wish you all the best in your project and design. And I hope you have as > much fun working with this great framework, that Mauro and others have > generously build and do a great job at maintaining, as we do.**** > > ** ** > > Happy JBehaving!**** > > Enrique**** > > ** ** > > *From:* Hans Schwäbli [mailto:[email protected]] > *Sent:* Monday, September 23, 2013 6:04 AM > > *To:* [email protected] > *Subject:* Re: [jbehave-user] Do I really need Page Objects?**** > > ** ** > > 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**** > > **** > > **** > > **** > > ** ** >
