failSame, failNotsame and failNotEqual functions not working properly about shunit2 HOT 7 CLOSED

The patch does not include fixes to the unit tests. As such, this patch fails
testing. Could you please resubmit the patch, but one that fixes the unit tests 
as well?

(In reply to comment #1)

> The patch does not include fixes to the unit tests. As such, this patch fails
> testing. Could you please resubmit the patch, but one that fixes the unit 
tests as 
> well?

Sure, but first let me ask you a doubt about the documentation of such those 
failXXX
functions, since it's a bit confusing to me and I'd prefer to be sure before 
sending
another incorrect or incomplete patch to you :-).

From
http://shunit2.googlecode.com/svn/trunk/source/2.1/doc/shunit2.html#shelldoc-sec
tion-failures:

-failSame([message]):Indicate test failure because arguments were not the same. 
The
message is optional.

Is this ok? I'd understand that this function should fail when arguments were 
the
same, and not the other way around

-failNotsame([message],expected,actual): Fails the test if expected and actual 
are
equal to one another. The message is optional.

Is this ok? Because of the same reason explained for failSame, I'd understand 
this
function should fail when arguments were NOT the same, and not the other way 
around.

In other words, I would say the description for failSame and failNotSame is 
swapped,
isn't it?

Thanks in advance.

Mario

As I myself am not really sure either, I will look into PyUnit, and perhaps 
some xUnit documentation on what the 
actual functionality should be. You are correct that the documentation does not 
match the functionality, so one 
or the other needs to be fixed.

If you happen across some good documentation for another unit testing framework 
that is clear on this, I'd be 
glad to look at it.

Looking at some xUnit documentation on Single Outcome Assertions 
(http://xunitpatterns.com/Assertion%20Method.html#Single%20Outcome%20Assertion) 
I found a section that 
talks about failNotEquals. "The method failNotEquals is a Test Utility Method 
that fails the test and provides a 
diagnostic assertion message."

Basically, shUnit2 is doing the correct thing in that the failNotEquals is not 
an assertion, meaning it is not 
testing that the values are equal or not. It is supposed to provide a nice 
message explaining that the values 
are not equal, but it never actually tests them. They have a code sample in 
Java that clearly demonstrates its 
usage, so I will look at porting that sample to shell and including it in the 
documentation.

Hmmm... So after all it seems the current shunit2 is working properly, that is, 
just
always failing regardless of the passed values being equal or not... therefore 
the
only bug in shunit2 would be in the documentation :-)

IMO, this is pretty clear as far as I understand from the following excerpt 
(from
http://xunitpatterns.com/Assertion%20Method.html#Single%20Outcome%20Assertion)

   /**
    * Asserts that two objects are equal. If they are not
    * an AssertionFailedError is thrown with the given message.*/
   static public void assertEquals(String message, Object expected, Object actual) {
      if (expected == null && actual == null)
         return;
      if (expected != null && expected.equals(actual))
         return;
      failNotEquals(message, expected, actual);
   }

It seems the failX functions are no more than private helper functions, but the 
real
test of the values must be performed previously. In fact, in JUnit the 
failNotEquals
function is a static private function indeed: 

http://www.javaresearch.org/source/junit3.8.1/junit/framework/Assert.java.html

So, it seems there's no need of any patch after all, and that I just 
misunderstood
the meaning of the functions, so excuse me for the "noise" :-)... and thanks a 
lot
for your work in shUnit2: I'm using it from some weeks in my day-a-day work and 
it
works like a charm!

No worries! And I don't mind the noise as it required me to actually do the 
research to verify why JUnit did what 
it did. I hadn't understood that before either believe it or not.

I'm leaving this bug open until I have fixed the documentation.

Fixed in revision# 246.