The way I see this is you have two issues to be addressed, one is that you want automatic testing in some situations but overall you also want to have testing being accomplished on this application you have. There are a few different ways to go about this, but you do need first to generate an overall strategy, as someone mentioned, what is your goal? What do you want to achieve by "testing"?

Most QA organizations will generate documentation that notes the overall strategy, the what will be done, and plans that will note the how. You don't need anything that formal but having even a napkin with a sketch of what you want to do will be helpful because it will make sure that you have a way to see and accomplish your goals. Most testing examples are high level, because everyone's needs, environment and code is different. What I may be testing is different from someone else, we may use the same underlying techniques of unit and boundary testing, but the methods we use will be different. If you've been reviewing some information on testing so far I'll go with the premise that you already have the basics down and know that you need to test but need to come up with a how. One way to handle this, if you have a project that is open source, is to open it up for people to test. Getting general feedback from people willing to test your project will give you different views on how its used and if you don't have Users giving you feedback its a good way to get a view from outside your own. Looking at sites like the Software Testing Club, Test Republic or SQA Forums you may find a few souls willing to test out your product.

Automation on the other hand is something you really need to plan out, basically its a software project in itself. If you have web interfaces that need testing you need a GUI test run, if its web based and not complex there are plenty of open source web tools to use. There are quite a few books out there on automation, including Implementing Automated Software Testing a recent one by Elfriede Dustin. If you have a sufficiently complex project then look at a framework you can run so that if you check in code you can do a build and have the framework run your tests; very useful in Regression Testing.

Expect that you will probably need to adjust your tests, yes you will write them AFTER you write code, anyone who suggests otherwise is being disingenuous. Tests that are stale will be as useful as the day they were written, proper testing needs as much care as writing code. For the last part of your post, you only need as much of a framework for testing as will allow you to exercise the code you are trying to test. Most QA organizations would love to have a mirror of production for what code is released, its not always possible so you go for the most bang for your buck and time. Set up what will allow you to test your code in a real world environment, set up scripts or situations that will allow you to test your code and if you need it think as well about what you can do to provide stress and load on the system.

If this is just you my suggestion would be trying to get others to test for you, or provide beta code for people to use before you release. The more you can get people to help you out, the more eyes and different perspectives you can get.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.