Paul Carvalho wrote:
> Bah! Lectures! You want to lecture me on how to test!?
No, I wanted the fetched Google pages to lecture you.
> If my focus were on Unit/Integration Testing, I would likely agree with
> you. That is, you set up the tests, perform the required steps and checks
> and then tear them down to a known, good state. If you do that, why
> should
> you care what order you run them in? However, I am a System/Black-Box
> tester and during a particular test run, the system gets into fairly
> complex
> setups that would be rather stupid to close the web browser between each
> test. There is no *reset* between tests.
That is an example of poor design-for-testing. Regardless how complex a user
may find a path from program load to some given state, tests should simply
have a back-door to that state, such as test resources with fixed data
tables.
However, there are much more excessive examples of poor design-for-testing
than just using GUI tests to test the back-end, so carry on!
> Just as everyone's definition of what a "test" might be, so we should
> respect that the order in which the tests need to be executed may be
> different. The addition of the feature to specify an order to the test
> cases is a valuable one that acknowledges that Watir is not only a tool
> for
> unit/integration/developer testing.
Then prefix all the steps methods with step_, and call them all from one
test case:
def test_universe()
step_bigBang()
step_inflationPhase()
step_condensatePhase()
step_quasarIgnition()
# etc
end
--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
_______________________________________________
Wtr-general mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wtr-general
