Are the developers doing (or writing) unit tests? I'm assuming your developed code is not based on ruby or rails but some other language. But that should be no problem as most languages allow unit testing. Chuck is steering you in the right direction with test first design. Cucumber works great for this. And if you're testing code that has no automated unit tests then Watir is perfect to drive through the UI.
On Monday, August 26, 2013 2:02:11 PM UTC-5, Jorge Gastaldi wrote: > > 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. 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.
