Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of alexey.a.petrenko@gmail.com
 designates 64.233.162.207 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=UNTTIYQOnO6ef0sf5lpnFqK3ekb9C+BYf7Ttn/wgwZLQDZ4ITO3iVR1GmtO1ZAV/9gmIfQAXEGJgASgqt2TEhqwgW3Z5JkJxJi0igtvVJdtxOinHL1CIaGeI23xx6biY+vlp6bTwXR+3r+n+t9FZSg7V58jeSwoQruSQzZssSmo=
Message-ID: <c3755b3a0607200029p4cc52618ge5b2d806135d3f4e@mail.gmail.com>
Date: Thu, 20 Jul 2006 11:29:50 +0400
From: "Alexey Petrenko" <alexey.a.petrenko@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [testing] locale dependent tests
In-Reply-To: <44BF221A.3030005@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <44BC99FA.1000103@gmail.com> <44BC9E43.3090405@gmail.com>
	 <44BCB94B.7070607@gmail.com> <44BCC1AC.2030402@gmail.com>
	 <44BCC6A1.9030509@gmail.com> <44BD9C74.6020201@gmail.com>
	 <44BDF608.60906@gmail.com> <44BE0583.4040609@gmail.com>
	 <4d0b24970607190846p63a02f57r673a515f73fc97c3@mail.gmail.com>
	 <44BF221A.3030005@gmail.com>

Sounds reasonable.

SY, Alexey

2006/7/20, Paulex Yang <paulex.yang@gmail.com>:
> Andrew Zhang wrote:
> > On 7/19/06, Richard Liang <richard.liangyx@gmail.com> wrote:
> >>
> >>
> >>
> >> Tim Ellison wrote:
> >> > Richard Liang wrote:
> >> >
> >> >> Although the spec does not require the round-trip of applyPattern and
> >> >> toPattern, we still want to get one *certain* pattern through
> >> toPattern.
> >> >> Now the problem is the returned pattern is locale-dependent. I'm
> >> >> uncertain about the reason to remove the assertion:
> >> >> 1) Because the behavior is not required by spec, or
> >> >> 2) Because the behavior is locale-dependent
> >> >>
> >> >
> >> > It would seem that rather than forcing the locale to be en_US to make
> >> > the test assertions valid, you could work with the default locale and
> >> > guard any assertions that are locale-specific.  It would seem a
> >> shame to
> >> > loose the diversity of testing on multiple locale machines if the
> >> tests
> >> > always force everyone to look like an American (horror! ;-) )
> >> >
> >> > I would expect the fix therefore to be something like, if locale is
> >> > en_US go ahead and assert more round-tripping code, otherwise can't
> >> test
> >> > it as the spec allows variances.
> >> >
> >> >
> >> If a test case passes in all locales, could we think that the behavior
> >> tested by the test case is locale-independent? We still have to think
> >> about how to test locale-dependent behavior. For example,
> >> java.util.Locale.getDisplayName() and java.lang.String.toUpperCase(). To
> >> verify both the code logic and locale data, shall we have some tests
> >> like ABC_en_US_Test, ABC_en_UK_Test, and ABC_ru_RU_Test?
>
>
> I still confuse what we want to test, the logic or the data? I think
> most (if not all) i18n related methods actually have same single
> executable with multiple resource bundles, i.e., the single executable
> should be locale-independent, the different return value is due to the
> resource data difference. I think at least for now, we should pay our
> attention to logic of single executable, and leave the data verification
> to the i18n libraries' author, say, ICU, they have much more knowledge
> and authority (at least than me) on this area.
>
> If we can get agree on the above, so the i18n related test cases
> organization are easier to judge: the logic is locale-independent, so
> ideally the tests should be locale-independent, but we have some
> exceptional cases, say, the en_UK in MessageFormat case, so we cannot
> make our tests rely on the default locale, then we just specify one
> locale(en_US) to the tests, and supplement some exceptional case when we
> find some. i.e., I don't think we need ABC_en_US_Test, or so.
>
> Comments?
>
>
> >
> >
> > Hi Richard,
> > For getDisplayName, getDisplayLanguage() and methods like so, which are
> > locale-dependent, I suggest we write implementation tests for them.
> > The test
> > may look like:
> > 1. get default locale
> > 2. get i18n string from ResourceBundle directly
> > 3. get i18n string by locale-dependent method
> > 4. assertEquals
> If we write test cases like this, these tests are probably
> locale-independent, because: the executable is probably single. I don't
> think we should have many "locale-dependent" methods, we just have many
> methods with "locale-dependent" data.
> >
> > Sounds reasonable?
> >
> > Any comments? Thank you!
> >
> > Best regards,
> >> Richard
> >>
> >> > Regards,
> >> > Tim
> >> >
> >> >
> >>
> >> --
> >> Richard Liang
> >> China Software Development Lab, IBM
> >>
> >>
> >>
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Alexey A. Petrenko
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org