Motivation
We need to externalize all the strings we use in our locators, such as "User order number" or validation methods, such as "Order Created." Why?- It'll make your code more maintainable if that string changes
- It keeps things organized
- Internationalization (i18n)
- Multi-platform automation
This works well for automating small to medium apps that themselves maximize code reuse. But for big (or legacy) applications it may not be the best approach due to non-standardization, your mileage may very.
And for multi-platform automation... (there is a lot more work involved, but this is part of the deal...)
Ok I'm going to be honest right now. I wrote the part above tonight and this next part 2 years ago and I don't even know what language this is. The filenames are .cs but I don't even know C# well enough to know if you can define methods like this, I might have just used .cs because gist colorization was good. Hmm, now I'm thinking it's just pseudocode.
Anyway, the last thing I'll say about externalizing strings is about dynamic strings.
Here's option 1, strings live in the data file and you compose them in the page object class:
This is fine, but will require everyone who uses those strings to do all that string concatenation themselves, which is code duplication. It will also become a problem when the translation is weird. Maybe in American English we'd say "Order number 404 is on its way!" but in Canadian English they'd say "404 is the number of the order comin' at ya, eh!" If this were the case, our stringA + orderID + stringB wouldn't work, or would be wonky. Let's just write methods to generate those strings instead, and notice how it's used in the page class:
And you could even get really crazy and do kind of a mix, which lets you have both the individual strings as well as the pre-composed dynamic strings. It just depends on what you need for your situation:
No comments:
Post a Comment