Comments on: Pitfalls of Exception expectations in JsUnit http://blog.caplin.com/2010/01/29/pitfalls-of-exception-expectations-in-jsunit/ Single Dealer Platforms, Industry Expertise Thu, 02 Feb 2012 04:16:03 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Ian Alderson http://blog.caplin.com/2010/01/29/pitfalls-of-exception-expectations-in-jsunit/comment-page-1/#comment-213 Ian Alderson Tue, 02 Feb 2010 09:14:20 +0000 http://blog.caplin.com/?p=1084#comment-213 This is a good point, and is indeed one of the approaches seen in our test code. This wouldn't help if the particular error message contained variable values that were inserted via tokens, however this argument only covers a subset of the exception cases. This is a good point, and is indeed one of the approaches seen in our test code. This wouldn’t help if the particular error message contained variable values that were inserted via tokens, however this argument only covers a subset of the exception cases.

]]> By: Adam Iley http://blog.caplin.com/2010/01/29/pitfalls-of-exception-expectations-in-jsunit/comment-page-1/#comment-174 Adam Iley Fri, 29 Jan 2010 14:52:41 +0000 http://blog.caplin.com/?p=1084#comment-174 > This particular approach has been met with trepidation from some of our developers who are concerned that verification of exceptions will lead to fragile test code, prone to break if someone changes the text within an exception One way around this is to store the error message in a string on the class which can be then refered to both in the throw in the code, and the assert in the test. > This particular approach has been met with trepidation from some of our developers who are concerned that verification of exceptions will lead to fragile test code, prone to break if someone changes the text within an exception

One way around this is to store the error message in a string on the class which can be then refered to both in the throw in the code, and the assert in the test.

]]>