I repeat, this is BAD AUTOMATION PRACTICE. You can find many many a resource on effective automation that tell you not to do this. Here's an example from this page http://xunitpatterns.com/Principles%20of%20Test%20Automation.html
Principle: Keep Tests Independent > *Also known as: *Independent Test > When doing manual testing <http://xunitpatterns.com/manual%20test.html>, > it is common to have long test procedures that verify many aspects of the > SUT's behavior in a single test. This is necessary because the steps > involved in setting up the starting state of the system for one test may be > simply a repetition of the steps used to verify other parts of it's > behavior. When tests are executed manually, this repetition is not > cost-effective. As well, human testers have the ability to recognize when a > test failure should preclude continuing execution of the test, when it > should cause certain tests to be skipped or when the failure is irrelevant. > If tests are interdependent and (even worse) order dependent, we will be > depriving ourselves of the useful feedback test failures provide. > *Interacting > Tests* <http://xunitpatterns.com/Erratic%20Test.html#Interacting Tests> (see > Erratic Test on page X) tend to fail in a group. The failure of a test > that moved the SUT <http://xunitpatterns.com/SUT.html> into the state > required by the dependent test will lead to the failure of the dependent > test too. With both tests failing, how can we tell if it is because of a > problem in code that both rely on in some way or is it a problem in code > that only the first relies on. With both tests failing we can't tell. We > are only talking about two tests here. Imagine how much worse this is with > tens or hundreds of tests. > An Independent > Test<http://xunitpatterns.com/Principles%20of%20Test%20Automation.html#Independent > > Test> can be run by itself. It sets up its own Fresh > Fixture<http://xunitpatterns.com/Fresh%20Fixture.html> (page > X) to put the SUT <http://xunitpatterns.com/SUT.html> into a state that > lets it verify the behavior it is testing. Tests that build a Fresh > Fixture <http://xunitpatterns.com/Fresh%20Fixture.html> are much more > likely to be independent than tests that use a Shared > Fixture<http://xunitpatterns.com/Shared%20Fixture.html>(page > X). The latter can lead to various kinds of *Erratic > Tests*<http://xunitpatterns.com/Erratic%20Test.html> > including *Lonely Tests*<http://xunitpatterns.com/Erratic%20Test.html#Lonely > Test> > , *Interacting > Tests*<http://xunitpatterns.com/Erratic%20Test.html#Interacting Tests> > and *Test Run Wars* <http://xunitpatterns.com/Erratic%20Test.html#Test > Run War>. With independent tests, unit > test<http://xunitpatterns.com/unit%20test.html> failures > give us Defect > Localization<http://xunitpatterns.com/Principles%20of%20Test%20Automation.html#Defect > > Localization> to help us pinpoint the source of the failure. On Wednesday, June 20, 2012 3:49:16 AM UTC-7, Doris Tian wrote: > > Thank you so much. I find this link > http://wiki.openqa.org/display/WTR/Test+Unit is talk about the order of > unit test. Followings are some parts I picked up from it: > > When we run the test script from the command line, Test::Unit uses > reflection to go through our test class and execute all the test cases > declared in it. The runner by default executes the test cases > alphabetically, so if you need to chain test cases, prefix letters from the > alphabet or numbers after the *test* prefix to force them to run in > order. ex. test_a_mytest. > > Note: If you use numbers in your method names, note that 1, 2, 3, 4, 5, 6, > 7, 8, 9, 10, 11, 12 will be executed in this order: 1, 10, 11, 12, 2, 3, 4, > 5, 6, 7, 8, 9. Instead, use this format: 01, 02, 03, 04, 05, 06, 07, 08, > 09, 10, 11, 12. ex. test_01_mytest, test_02_mytest, test_03_mytest will run > in the order expected. > But in my test scripts: I totally have 24 cases in 24 ruby files, and they > are named as test01.rb, test02.rb.......test24.rb. When I run these cases > through the bat file. The order is 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, > 11, 12, 14, 15, 16, 17, 18, 20, 21, 23, 13, 19, 22, 24. This order confused > me. I don't know why it will skip 13 and 19 and 22, but finally all the > cases are run. > > Thanks > Doris > > On Wednesday, June 20, 2012 4:38:37 PM UTC+8, Chuck van der Linden wrote: >> >> Test unit presumes your tests are atomic, not chained, and does not run >> tests in any particular order that I know of. >> >> This is a common problem for people with bad automation habits. Your >> tests should each take care of creating data they need, and cleaning up >> after themselves, so that you can run any test, in any order, or even in >> parallel (in order to do things like test different browsers at the same >> time, or execute across multiple servers to speed up test execution. >> >> If your tests need to be run in a particular order, you have a bad test >> design. it's a common test automation 'code smell' >> >> Test Unit was designed primarily for unit tests, and well written unit >> tests are always atomic in nature. >> >> On Tuesday, June 19, 2012 1:31:34 AM UTC-7, Doris Tian wrote: >>> >>> sorry for my mistake. >>> >>> Hi all, >>> >>> Here's a new problem, I don't know the reason. >>> >>> I write automation scripts with ruby & watir. >>> The structure of the scripts is as followings: >>> 1. I write every test case in different ruby file named as test01.rb, >>> test02.rb, test03.rb >>> 2. I divide the function of the scripts into three parts, and put them >>> into 1.rb, 2.rb and 3.rb according to the function. >>> 1> 1.rb such as (there are 24 files in 1.rb) >>> require 'test1/test01.rb' >>> require 'test1/test02.rb' >>> require 'test1/test03.rb' >>> require 'test1/test04.rb' >>> …… >>> require 'test1/test24.rb' >>> 3. I create a bat file to run all the ruby file (1.rb, 2.rb, 3.rb), >>> using 'ruby -Ku -rjcode 1.rb' >>> >>> The problem is: >>> when I run the bat file, it will run the test cases in the 1.rb, I think >>> it will run the files according to the sequence I write. it will run as: >>> test01.rb, test02.rb, ……test24.rb. >>> BUT, the actual result is: it runs test01.rb -----test12.rb, but it will >>> skip test13.rb to run test20.rb. and then will run test14.rb, test15.rb. >>> I'm confused that. >>> Could you give me some advice? >>> >>> Looking forward to your reply. >>> >>> Thanks >>> Doris >>> >> -- Before posting, please read http://watir.com/support. In short: search before you ask, be nice. [email protected] http://groups.google.com/group/watir-general [email protected]
