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 >> >> >> >> >
