Java/ JUnit - AssertTrue vs AssertFalse

I'm pretty new to Java and am following the Eclipse Total Beginner's Tutorials. They are all very helpful, but in Lesson 12, he uses assertTrue for one test case and assertFalse for another. Here's the code:

// Check the book out to p1 (Thomas)
// Check to see that the book was successfully checked out to p1 (Thomas)
assertTrue("Book did not check out correctly", ml.checkOut(b1, p1));	// If checkOut fails, display message
assertEquals("Thomas", b1.getPerson().getName());
	
assertFalse("Book was already checked out", ml.checkOut(b1,p2));		// If checkOut fails, display message
assertEquals("Book was already checked out", m1.checkOut(b1,p2));

I have searched for good documentation on these methods, but haven't found anything. If my understanding is correct, assertTrue as well as assertFalse display the string when the second parameter evaluates to false. If so, what is the point of having both of them?

Edit: I think I see what was confusing me. The author may have put both of them in just to show their functionality (it IS a tutorial after all). And he set up one which would fail, so that the message would print out and tell me WHY it failed. Starting to make more sense...I think that's the explanation, but I'm not sure.

assertTrue will fail if the second parameter evaluates to false (in other words, it ensures that the value is true). assertFalse does the opposite.

assertTrue("This will succeed.", true);
assertTrue("This will fail!", false);

assertFalse("This will succeed.", false);
assertFalse("This will fail!", true);

As with many other things, the best way to become familiar with these methods is to just experiment :-).

Your understanding is incorrect, in cases like these always consult the JavaDoc.

> assertFalse > > public static void assertFalse(java.lang.String message, > boolean condition) > > Asserts that a condition is false. If it isn't it throws an AssertionError with the given message. > > Parameters: > > * message - the identifying message for the AssertionError (null okay) > * condition - condition to be checked

The point is semantics. In assertTrue, you are asserting that the expression is true. If it is not, then it will display the message and the assertion will fail. In assertFalse, you are asserting that an expression evaluates to false. If it is not, then the message is displayed and the assertion fails.

assertTrue (message, value == false) == assertFalse (message, value);

These are functionally the same, but if you are expecting a value to be false then use assertFalse. If you are expecting a value to be true, then use assertTrue.

I think it's just for your convenience (and the readers of your code)

Your code, and your unit tests should be ideally self documenting which this API helps with,

Think abt what is more clear to read:

AssertTrue(!(a > 3));

or

AssertFalse(a > 3);

When you open your tests after xx months when your tests suddenly fail, it would take you much less time to understand what went wrong in the second case (my opinion). If you disagree, you can always stick with AssertTrue for all cases :)

Your first reaction to these methods is quite interesting to me. I will use it in future arguments that both assertTrue and assertFalse are not the most friendly tools. If you would use

assertThat(thisOrThat, is(false));

it is much more readable, and it prints a better error message too.

assertTrue will fail if the checked value is false, and assertFalse will do the opposite: fail if the checked value is true.

Another thing, your last assertEquals will very likely fail, as it will compare the "Book was already checked out" string with the output of m1.checkOut(b1,p2). It needs a third parameter (the second value to check for equality).

The course contains a logical error:

	assertTrue("Book check in failed", ml.checkIn(b1));
	
	assertFalse("Book was aleready checked in", ml.checkIn(b1));

In the first assert we expect the checkIn to return True (because checkin is succesful). If this would fail we would print a message like "book check in failed. Now in the second assert we expect the checkIn to fail, because the book was checked in already in the first line. So we expect a checkIn to return a False. If for some reason checkin returns a True (which we don't expect) than the message should never be "Book was already checked in", because the checkin was succesful.