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
