Well the parallel between page objects and XML seems rather far fetched IMO.
I would the PO more to using a builder pattern when doing unit testing. Some might feel the builders are redundant but others find them to increase readability, maintainability and reusability. On 26 Sep 2013, at 14:33, Hans Schwäbli <[email protected]> wrote: > Hello Iulian Greculescu, > > I don't understand what you mean with "how" and "what" in the context of > steps and page objects. > > I know that steps and page objects differ in their purpose. > > What I am thinking is that page objects are obsolete when using steps. They > might be nice to have, but you need to write and maintain them. If something > is acutally obsolete, you don't want to invest in this kind of extra work. > > I feel like years ago when I discussed why Ant build scripts are written in > XML instead of a scripting language. Nearly everyone in the forum wrote that > XML is a god idea for a build tool. Now we have Gradle and Ant can be used > with Groovy. I feel that Ant's XML is todays page objects for JBehave. > > But I might be wrong. I will try it without page objects and then see for > myself if I am right or wrong. > > > > 2013/9/26 Hans Schwäbli <[email protected]> >> Hi Stephen, >> >> your argument seems interesting, you say that with an abstraction layer >> below JBehave Steps you can run the tests on different clients. >> >> Could this also be achieved with Step candidates? You could have step >> candidates for different clients and configure them as you need it. >> >> I would write a story with a scenario called "logon" and another story with >> a scenario "logoff". Whenever I need it in another story I would declare >> "GivenStories" and reference it. >> >> Concerning navigation: What about writing a Steps class dealing with it? For >> instance we could use steps like "user is on shopping cart page" or "user is >> on contact page". >> >> Well, I need some experience with it, then I will know. >> >> >> >> 2013/9/26 Iulian Greculescu <[email protected]> >>> Hi Hans, >>> >>> Pages are another layer which group your steps based on the business/user >>> experience in interacting with the system under test. The closer to the >>> system model your testing implementation is the clearer and easier to >>> understand and maintain. >>> The page is about “what” the system does and can stay unchanged for ever. >>> The steps are more about “how” that page is behaving which in turn means >>> “how” the system does things. From a user experience point of view they do >>> not care about “how”, and they should not. For them the only one important >>> thing is the “what” and that the actual “what” is the expected one. Having >>> a page helps us to better encapsulate a part of the system and simulate we >>> expose just that one to the user. >>> In my opinion testing “what” is all BDD is about leaving the “how” to >>> integration/unit testing. A page is just a clearer way to expose that >>> “what”. >>> Metaphorically speaking looking at a “page” will always help you to better >>> understand what the system is doing than reading a document describing >>> “step by step” how things work in that page. >>> Finally because you seem not to mind an ironic sentence, then as many >>> others pointed here, it is up to the individual to decide what it is most >>> suitable for them. Some may argue why do we need java/scala/jBehave or >>> whatever when we have assembler already :-) >>> Cheers, >>> >>> From: Stephen de Vries <[email protected]> >>> To: [email protected] >>> Sent: Tuesday, 24 September 2013 5:58 PM >>> >>> Subject: Re: [jbehave-user] Do I really need Page Objects? >>> >>> >>> Hi Hans, >>> >>> I'm working on a project where the requirement is to have a single set of >>> re-usable tests that can be run against a number of different web >>> applications. I found page objects a bit too cumbersome for this task, so >>> instead I used a single class that represents the application, with methods >>> in that class representing the functions of the app. So for example: >>> >>> public class MyApplication extends Application { >>> >>> public void gotoLogonPage() {..} >>> public void logon(String username, String password) {...} >>> public void logoff(); >>> ...other common functions... >>> } >>> >>> Using this abstraction layer, the JBehave tests can now be completely >>> independent from the application under test so I can run the same tests on >>> different apps without ever changing any jbehave step code. (The tests are >>> functional security tests, so they're concerned with functionality which is >>> common to most web apps). >>> >>> Granted that not everyone wants to test multiple apps with the same tests, >>> but another benefit is that using an abstraction layer you have all the >>> code that navigates your app in one place. If you rely on Steps for this >>> then you have a mixture of navigation code and testing code in the same >>> class. I think it's neater to separate the two. >>> >>> >>> >>> > >>> > On 24/09/2013 06:05, Hans Schwäbli wrote: >>> >> 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 >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> > >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >
