I'm fairly new to writing test cases and this will be my first major project, but I'm kind of confused on how to design a framework (I know this is not the right word, but I'm not sure that word I'm looking for here).
The application that I am testing involves creating a database of clients by filling out web forms and under each client are other forms that can be filled out and saved. The system is a bit more complicated than that as there are conditions that must be met before certain forms are filled, or certain answers cannot be chosen unless some preconditions are met.
From my research, I've seen that a good way of going about this is by creating a module for every page, where a method is defined for each function on that page.
So by that idea, for a page with lets say 40 text fields, would I create a method for each text field called "fill_fieldname"?
I'm also concerned as to how I would go about atomizing the test cases when there are preconditions. For example if I need to test a specific form's functionality, I would first need a client to exist. Should I create a new client for every scenario that I'm testing, or just use one client for all the scenarios? I suppose that I'd have to do a precondition check before each test case to ensure that the client is still "usable" for testing...
I'm really confused as to where to start, and I'd like to very much design a good framework from the get go, rather than have to scrap everything after the project has gotten too large. Any tips/advice would be very much appreciated.
Most folks are going to pair watir-webdriver with an existing page framework like cucumber or rspec for organization and validation. After that, I believe you were referring to page object pattern framework for ease of use and ease of expansion. You can find some great guides here:
Writing the test cases manually is a very important step of any automated process. Someone once said that automation without quality manual strategy lets you make mistakes much faster than you normally could (I'll take credit if no one else does).
Hopefully you have some good documentation for the application or someone providing you business/use cases for the product. It is very easy to generate test cases from business cases. Then, just go step by step and break it up in feature sets.
It can also be difficult to think about the application end-to-end and try to encompass all of that functionality in your tests from the start. Before you have a robust framework, you may just have some simple tool-type tests that help you set up manual testing faster, or perform tests with meaningful (but not beautiful) output. It's all part of the process. You WILL scrap some of what you do, but of course you don't want to scrap ALL of it. Keep it simple, make it modular - all traditional development concepts like DRY, KISS apply here.
Good automated tests are born from great manual test cases. If you try to skip this step (and don't have extensive experience), you will regret it!
There are lots of good testing books. I personally enjoyed Lessons Learned in Software Testing - one of the authors is Bret Pettichord, the founder of WATIR.
Once you get the testing fundamentals down, you can get into library-specific books like the WATIR Book, or many of the online blogs linked to/from the aforementioned Watirmelon and Cheezy.