On Wednesday, June 20, 2012 6:22:24 PM UTC-7, Doris Tian wrote:
>
> I got it, thank you so much, I will pay much attention to the following 
> work.
>
> Here is a new hot problem blocked me, I was confused by this issue for 
> several weeks. Could you take a look and give me some advice? 
> Here is the link: 
> https://groups.google.com/forum/?fromgroups#!starred/watir-general/Om5dyceOtjM
> Or you can search the topic: watir & ruby: cannot write double-byte 
> characters in IE
>
>
> Waiting for you kind reply.
>
> Thanks 
> Doris 
>

Saw it, didn't have anything to add as I have been blissfully excused from 
having to deal with any DBCS stuff  since the days when I tested things 
going into Windows 95, 98, and Win2K
 

>
> On Thursday, June 21, 2012 2:50:18 AM UTC+8, Chuck van der Linden wrote:
>>
>> 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]

Reply via email to