Jorge,
If I were in that situation I'd try to get the developers to write page
objects. I'd write some info about what page objects are out there and about
how the page objects should be defined, maybe with an example, so that the
developers could talk about it come up with a consensus and implement things in
a consistent way. Actually, I haven't used any of the page objects libraries
yet as it's pretty simple to come up with a container. I plan to play around
with them at some point though when I have more time.
It's also useful to create non page object classes for commonly used things in
the ecosystem (e.g., Person, Organization). You can do some interesting things
with these classes. One thing I really like to do is to use Activerecord to
give the object access to relevant tables. For example, you could have a Person
class and then use Activerecord to write a method to return all of the
organizations that the Person belongs to (probably as Organization objects).
Then you can do stuff like:
p = Person.new(:name=>'blah')
o = Organization.new(:name=>'BLAH')
assert(o.persons.include?(p), "Org #{o.name} did not include person #{p.name}")
#Even better, make string representation of the Org and Person classes to be
the name
b = Watir::Browser.new
p = Person.new(:name=>'blah')
p.organizations.each do |org|
page = OrganizationPage.new(b)
assert(page.person_name == p.name)
end
For all of the CRUD stuff, creating an object that has mapping to the relevant
DB tables for the object is awesome. Then you can use the page object to delete
the person from the org and then call the person object to see if it still
thinks it belongs to the org. No SQL. You just need to do a little setup in
activerecord to get everything in a table for a particular ID.
There are nicer ways to do the stuff above.I'm sure other people will have
other ideas.
One thing you want to do (no matter what): treat the automation effort as a
serious development task. It's really important to keep things organized and
done in a consistent way.But it sounds like you're already thinking about that
________________________________
From: Jorge Gastaldi <[email protected]>
To: [email protected]
Sent: Monday, August 26, 2013 12:02 PM
Subject: [wtr-general] Re: Testing Methodology with Watir
Thanks for your response!
Those patterns point directly to some of the problems that I want to attack.
But most of my developers never touched ruby, so maybe a "just make some
procedures" approach can be better for a first stage, and then move to a better
structured one.
But my main concern is at a higher level. Let's say we have two teams:
development and testing. Testing wants to automate some tests with Watir, but
that implies that they need an intimate knowledge of the application
implementation. I want to avoid that, because both effectivity and efficiency.
So my plan tries to answer: How can the Testing team do automation with Watir
keeping some separation of concerns between Testing and Development?
I guess my question for the group should be more general: How Testing teams use
Watir?
On Friday, August 2, 2013 6:43:33 PM UTC-3, Chuck van der Linden wrote:
On Monday, July 22, 2013 11:05:38 PM UTC-7, Jorge Gastaldi wrote:
>
>
>>
>>
>>
>> This is something that must be somewhere on the net, but I couldn't find.
>>
>>
>> I have used Watir for some scripts, small things. But I think that could
>>be very nice to use it at work as an integral part of the development and
>>testing cycle. So I want to know about the best practices and usual
>>methodology for Watir for development and/or testing teams. One of my main
>>concerns is: if the testing team builds the Watir tests, they have to know
>>deep details of the web page implementation? That's something I would like to
>>avoid.
>>
>>
>>
>>
>> As couldn't find information about it, I've thinking and came up with a
>>little plan. I would be very grateful about any feedback about it.
>>
>>
>> We work mostly with CRUDs or CRUD-like web pages, so this could be a
>>generic work flow:
>>
>> * The developer finish a web page.
>> * He builds a set of Watir functions that only covers the Create,
>>Restore, Update, Delete functionality (if applies) and little more. For
>>example, "addPerson(personId, organisationId)".
>> * Then the testing team build the integration tests using this "high
>>level" functions. Something like:
>>
>>
>> organisationId = createOrganisation(...)
>> personId = createPerson(...)
>> addPerson(organisationId, personId)
>>
>>
>>
>>
>>
>> I see several advantages with this approach (that maybe is what
>>everybody is doing):
>>
>>
>> * The developers and testers get some useful functions to work with.
>>Very practical to setup some testing data for unit or other tests.
>> * If you have the functions, there was _at least_ a basic unit
>>testing. This shouldn't be a big advantage... but at some teams it is
>> * The testers don't have to know how the web page was implemented.
>> * The maintenance of the test cases should be pretty straight
>>forward: every time you change a web page, you now quite easily which
>>functions you should update. The integration tests will be also pretty easy
>>to find and even easier to fix.
>>
>>
>> Again, any feedback or advice is more than welcome.
>>
>>
>>
>>
>> Thanks in advance,
>> Jorge
>>
>>
>>
>>
>> (sorry about my English)
>>
>>
>>
>
>
>So my take on this is a little different. I'm a big fan of 'test first', at
>the code level this tends to mean unit tests. At the feature level a good
>approach is to use an "Executable Specification", and a good way to do that is
>"Specification by Example" (see http://www.manning.com/adzic/ )
>
>
>What tool you use for that depends on what languages you and your developers
>are comfortable with. If they are happy with Ruby, then using Cucumber along
>with Watir for those tests that are UI facing is a great choice. and in that
>case I strongly recommend reading 'the cucumber book' to get started in the
>right direction.
>
>
>Cucumber gives you one aspect of re-usable and maintainable code which is the
>idea of common steps that can be re-used.
>
>
>The other good practice is the Page Object and Data Object patterns.
>
>
>Page objects model the application's web pages and consist of logical names
>for page elements along with how those elements are identified. That gives
>you a way to address page elements by name in your scripts so that if the site
>changes, you have one place to change in order to update your scripts.
>
>
> Data objects do a similar thing for having a logical way to persist a 'test
>side copy' of data objects (such as users, items for sale in a store, a
>shopping cart) and also provide a way to pass that test data from one step to
>another in your code. Similar to page objects this also gives you one place
>to have methods for things like say updating a user profile, logging in, etc.
>Data objects typically have a set of default values for an object of that
>type, and you can create them using entirely the defaults, or overide any or
>all parameters as needed. A similar approach is used for methods that do
>things for filling out a form.
>
>
>Both of those are what are referred to as 'abstraction layers'
--
--
Before posting, please read http://watir.com/support. In short: search before
you ask, be nice.
[email protected]
http://groups.google.com/group/watir-general
[email protected]
---
You received this message because you are subscribed to the Google Groups
"Watir General" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
--
--
Before posting, please read http://watir.com/support. In short: search before
you ask, be nice.
[email protected]
http://groups.google.com/group/watir-general
[email protected]
---
You received this message because you are subscribed to the Google Groups
"Watir General" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
