Assert Equals Case Sensitive

[Bill Rawlinson]

Correct me if I'm wrong but doesnt AssertEquals in java always consider case sensitivity  -  thus I'm not sure "conforming to the standard api" is totally applicable.  While I fully understand the desire to maintain the api signature I don't think there is a real flaw in adding an optional parameter that gives AssertEquals the standard api behavior as well.

[Marc Esher]

the one thing that should at least be considered is readability.

as you're reading the test, which of these more easily communicates
your intentions:

assertEquals(expected,actual,"message",true)

or this:

assertEqualsCase(expected,actual,"message")

?

[Bill Rawlinson]

Well honestly I think assertEqualsCase should be there - but I also think that the optional parameter for assertEquals should be there too just because, to me, assertEquals already should consider case and, based on my other xunit experiences, assertEquals already means totally equal (including case).

[denstar]

On Fri, Jul 17, 2009 at 12:07 PM, Bill
Rawlinson<bill.ra...@gmail.com> wrote:
> Well honestly I think assertEqualsCase should be there - but I also think
> that the optional parameter for assertEquals should be there too just
> because, to me, assertEquals already should consider case and, based on my
> other xunit experiences, assertEquals already means totally equal (including
> case).

Yeppers, I think I agree. If anything, I would sorta think it would
be assertEquals() and assertEqualsNoCase().

.02 cents

--
No sadder proof can be given by a man of his own littleness than
disbelief in great men.
Thomas Carlyle

[Bill Rawlinson]

The only problem with changing assertEquals behavior is that it would very likely cause a lot of old tests to break (which would totally suck and seems really unacceptable).

[denstar]

On Fri, Jul 17, 2009 at 12:40 PM, Bill
Rawlinson<bill.ra...@gmail.com> wrote:
> The only problem with changing assertEquals behavior is that it would very
> likely cause a lot of old tests to break (which would totally suck and seems
> really unacceptable).

Yeah, that part sucks, but there's a real argument that it's broken as is.

CF is case sensitive when comparing strings... I wonder if it actually
wouldn't be that bad, because-- and correct me if I'm wrong but:

Wouldn't your actual code fail even if this assertion was true? At
least if you're using it with string comparison?

assertEquals("Me","me") might assert true, but something like
listContains("Me,Myself,I","me") would fail, right?

I'm probably missing something obvious, but that's my logic. *shrug*

Yeah, backwards compatibility is a real pain in something like a unit
test framework. Or version control, etc.. :-/

--
No violent extreme endures.
Thomas Carlyle

[Bill Rawlinson]

I agree with your logic completely - I just know you guys would get some nasty feedback if you broke a bunch of tests :O)

[denstar]

On Fri, Jul 17, 2009 at 12:52 PM, Bill
Rawlinson<bill.ra...@gmail.com> wrote:
> I agree with your logic completely - I just know you guys would get some
> nasty feedback if you broke a bunch of tests :O)

Assuming the logic holds, those tests are broken already. :-D

Longfellow said something that I think about from time to time:

Be still sad heart and cease repining;
Behind the clouds the sun is shining,
Thy fate is the common fate of all,
Into each life a little rain must fall,
Some days must be dark and dreary.

Seriously tho, if it's a problem for someone with thousands of tests
(I know they're out there, somewhere), maybe we could add a switch
that would revert to the old behavior? Stuff like that can appease
nasty feedbackers, sometimes. =]

--
None of us will ever accomplish anything excellent or commanding
except when he listens to this whisper which is heard by him alone.
Thomas Carlyle

[Marc Esher]

On Fri, Jul 17, 2009 at 2:52 PM, Bill Rawlinson<bill.ra...@gmail.com> wrote:
> I agree with your logic completely - I just know you guys would get some
> nasty feedback if you broke a bunch of tests :O)

I think you overestimate the actual usage of a unit test framework in
ColdFusion.

If jQuery broke something for the sake of purity vs. backwards
compatibility... yeah, the haters would be out.

unit test framework? not so much...

[Bill Rawlinson]

Well as much as I love TDD I guess I'm just an optimist :O)