do you use message field on assertions?

[Jeanne Boyarsky]

At Lasse's Server Side breakout session, I noticed he didn't have the String message parameter in any of the examples. When I asked, Lasse said he feels it makes the tests harder to read or doesn't add clarity or something like that.

The following are the first unit tests I've written since that discussion. I'm not clear how the message doesn't help.
If the tests fails, it says "java.lang.AssertionError: #attachments expected: <1> but was: <3>" instead of "java.lang.AssertionError: expected: <1> but was: <3>"
Here's a few reasons:
1) The failure message is more descriptive and tells me the magic numbers 1 and 3 pertain to the number of attachments.
1a) I don't need to click on the failure to see why it is failing
1b) If I have multiple assertions, I know which one is failing
1c) If the nightly build fails, I can see why without having to go to the code by looking up the line number
2) Writing a message string encourages the code author to think about what the assertion is testing.

I'm hoping Lasse or someone else with the same opinion reads this so I can better understand the reasoning. Or just know that it depends on circumstances. In a true TDD environment, I'm guessing some of these don't come up. (or aren't an issue since you wrote the offending code a minute ago)

   
    @Test
    public void ranchHand() {
        int expectedMax = SystemGlobals.getIntValue(ConfigKeys.ATTACHMENTS_MAX_POST);
        int actualMax = AttachmentCommon.getMaxNumberAttachments(userSession);
        assertEquals("# attachments", expectedMax, actualMax);
    }

    @Test
    public void moderator() {
        addRoleToSecurityRepository(SecurityConstants.PERM_MODERATION);
        int expectedMax = SystemGlobals.getIntValue(ConfigKeys.ATTACHMENTS_MAX_POST_ADMIN);
        int actualMax = AttachmentCommon.getMaxNumberAttachments(userSession);
        assertEquals("# attachments", expectedMax, actualMax);
    }