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. watir-general@googlegroups.com http://groups.google.com/group/watir-general watir-general+unsubscr...@googlegroups.com --- 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 watir-general+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
