[Junit-trackers] [ junit-Feature Requests-1565177 ] Be able to optionally specify expected exception message.

[SourceForge.net <no...@so...>]

Feature Requests item #1565177, was opened at 2006-09-25 15:50
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1565177&group_id=15278

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Bruce Dunwiddie (shriop)
Assigned to: Nobody/Anonymous (nobody)
Summary: Be able to optionally specify expected exception message.

Initial Comment:
NUnit allows you to optionally specify an expected 
exception message on an expected exception instead of 
just relying on the exception type.

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2009-12-01 02:20

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: David Saff (dsaff)
Date: 2009-11-16 17:52

Message:
This tracker is being shut down.  Please move this item to
http://github.com/KentBeck/junit/issues

----------------------------------------------------------------------

Comment By: Alex (toalexsmail)
Date: 2009-05-04 13:52

Message:
"timhobson" does your solution is extensible to check caused exception?
Type, error message and recursively it's cause. It will be very nice.

----------------------------------------------------------------------

Comment By: Alex (toalexsmail)
Date: 2009-05-04 13:50

Message:
You're not the only one. I wrote my post about a year ago and I still wait
for this feature (while I don't consider it critical).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-13 15:00

Message:
"nobody" says thank you for your interest!
It feel strange to me if i were the only one interested in this feature.
Do you plan to contribute to a next version of junit?

Franois Wauquier

----------------------------------------------------------------------

Comment By: Tim Hobson (timhobson)
Date: 2008-12-23 21:43

Message:
I recently implemented this functionality for my own purposes.  Is there
interested in me publishing the implementation for wider consumption?

I followed the pattern submitted by "nobody":

@Test (expected=SomeException.class, expectedMessage="Some Message")
public void method(){
 method();
}

I'm now working to find a way to make this even more extensible, where it
can assert on "error codes" or other attributes of the exception which are
specific to a type of Exception class.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-12-01 10:02

Message:
Junit3
public void testMethod(){
 try{
  method();
  fail();
 }catch(SomeException e){
  assertequals("Some Message",e.getMessage());
 }
}

Wanted Feature in Junit4
@Test (expected=SomeException.class, expectedMessage="Some Message")
public void method(){
 method();
}

It would be possible to specify the class, the message, both, or none of
them.

please.

----------------------------------------------------------------------

Comment By: Alex (toalexsmail)
Date: 2008-03-12 21:20

Message:
Logged In: YES 
user_id=2034775
Originator: NO

It will be also very nice to specify expected cause exception. It is
useful in the case of InvocationTargetException and EJBException. It should
be also nice to be able to note what "getCause()" method to call. For
example, in EJBException getCausedByException() should be  callled. In both
JBoss and Glassfish implementation getCause() always returns null.

It can be also nice to point on cause of the cause and so on. It is simply
to implement by recursion.

----------------------------------------------------------------------

Comment By: Bruce Dunwiddie (shriop)
Date: 2006-12-12 16:24

Message:
Logged In: YES 
user_id=479533
Originator: YES

Here's what my C# test case is using NUnit:

[Test()]
[ExpectedException(typeof(ArgumentNullException),
	"Data can not be null.\r\nParameter name: data")]
public void Test77()
{
	CsvReader.Parse(null);
}

Evidently, they don't actually have an example of using this constructor
overload in their online documentation, at least not that I can easily
find.

Here's my java test case done the best way I can come up with to
accomplish the same thing:

@Test
public void test77() {
	try {
		CsvReader.parse(null);
	} catch (Exception ex) {
		assertException(new IllegalArgumentException(
			"Parameter data can not be null."), ex);
	}
}

----------------------------------------------------------------------

Comment By: Santiago L. Valdarrama (svpino)
Date: 2006-12-12 15:41

Message:
Logged In: YES 
user_id=818352
Originator: NO

Could you provide a NUnit sample to see that behaviour in action?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1565177&group_id=15278