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 :) 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]<mailto:[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]<mailto:[email protected]>] Sent: Monday, September 16, 2013 9:20 AM To: [email protected]<mailto:[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]<mailto:[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
