commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: svn commit: r983219 - /commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringUtilsTest.java
Date Mon, 09 Aug 2010 11:39:41 GMT
On 9 August 2010 04:52, James Carman <james@carmanconsulting.com> wrote:
> On Sun, Aug 8, 2010 at 11:39 PM, sebb <sebbaz@gmail.com> wrote:
>> IMO the tests are now less stringent, e.g. they no longer distinguish
>> leading string parameters from varargs when calling
>> StringUtils.startsWithAny.
>>
>
> And, neither would the user's code.  We're using the code exactly as
> the user would be.  If we think this makes our API less-friendly, then
> why are we making the change?
>
>> As I wrote before, by all means add new vararg tests, but dropping
>> existing tests does not make sense to me.
>>
>
> I guess we'll have to agree to disagree on this one.  I'm not going to
> argue with you if you want to revert it.  I was just trying to do some
> code clean-ups.  If we're moving to JDK5, then we should code like
> we're using JDK5.  Our unit test code should reflect that.

Yes, but the library is also supposed to be usable with user code that
does not use the new features of JDK5.

> Remember, unit test code also serves as documentation to the user about how the
> API is supposed to be used.  It's sometimes the only "documentation"
> that actually stays in synch with the code itself.  If we have
> explicit String[] creation stuff in our test cases, folks might think
> that's required (or wonder why we're not just using varargs when we
> can).

Exactly.

If we don't have the String[] tests, then users may wonder if they
have to change all their code in order to use the new version.

We need to use both methods to show that both approaches are supported.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message