Ok, I need a boost on this thought process - my brain hurts. I'd like to get your feedback on some approaches.
I'll post my questions up front just in case I lose your attention during the description below:
Have you scripted a similar product before? How did you approach it?
Do any of these approaches stand out as great/terrible for any reason? If so, what?
There is a workflow that I am testing, for argument's sake we'll call it a shopping cart that consists of various text_fields, radio_buttons and select_lists. One company provides this shopping cart for ~60 clients, and not all of the clients use the same exact forms but the general process is the same. The general idea is the same between clients (same target functionality) and there are subsets of clients with the same exact workflow, but many that are unique. In this scenario, unique may mean that certain fields are not required while they may be for other clients. Or, certain questions/text_fields exist for one client that no others may use at all.
The goal of the script at this point is just to generate an order through the web interface, not to verify each individual step of the process as a 'test'. You'll have to trust me a bit here. There are still plenty of common details to be able to run negative/edge cases with an acceptable level of accuracy.
The approaches that I see so far are:
Using page object pattern, create a "page" file for each client site and use a different page Class depending on which client is being tested. This is tedious, mostly fragile and a lot of work to maintain. However, it would work and I could use the same feature/scenarios for everyone as long as their specific page file was accessible.
Create a method to scrape all of the input elements from the DOM, detect if they are a reserved field that we need to inject specific required input into, or just fill in information to get the order to complete. This does not piggyback on the DB so performance should be better overall.
Hook into the DB, gather all the information required by the specific client used to build their pages, and dynamically build the fields for the order, and answer them accordingly. This sounds great in theory, would require very little if any maintenance. DB scraping is easy, the difficulty building the fields is as yet unknown to me...
Right now I'm using: watir-webdriver cucumber Cheezy's page-object gem sequel
I would use cheezy's page-object and include every field/question that could be included. then I would overload the default values for each customer including only the fields/questions that they use. Hopefully, I did not oversimplify that.
Update: In the page populator, it will merge whatever you data send (as a hash) with default data. In his default data post, he shows how to use default data. I figure that you can create a class checkout page
class CheckoutPage
include PageObject
text_field(:name, :id => “order_name”)
text_field(:address, :id => “order_address”)
text_field(:email, :id => “order_email”)
select_list(:pay_type, :id => “order_pay_type”)
button(:place_order, :value => “Place Order”)
PageObject::PageFactory.routes = {
:default => [[HomePage, :select_puppy],
[DetailsPage, :add_to_cart],
[ShoppingCartPage, :continue_to_checkout],
[CheckoutPage, :complete_order]]
}
def complete_order(data = {})
data = DEFAULT_DATA.merge(data)
self.name = data['name']
self.address = data['address']
self.email = data['email']
self.pay_type = data['pay_type']
place_order
end
end
then overload it for specific vendors using the site and each has it's own default data.
class Nordies < CheckoutPage
DEFAULT_DATA = {
‘name’ => ‘cheezy’,
‘address’ => ‘123 Main Street’,
‘email’ => ‘cheezy@example.com’,
‘pay_type’ => ‘Purchase order’
}
PageObject::PageFactory.routes = {
:default => [[HomePage, :select_puppy],
[DetailsPage, :add_to_cart],
[ShoppingCartPage, :setup_creditcard],
[CreditCardPage, :continue_to_checkout],
[CheckoutPage, :complete_order]]
}
end
Then the .complete_order will be different for every vendor.