From: <gu...@st...> - 2002-02-18 16:56:00
|
The method assertEquals(String, String) is very useful, but breaks down with large strings. The problem is that, if the strings differ in only a few characters, or start to differ more than a few lines in, the error message is almost completely useless. expected:<HUGE STRING> but was:<NEARLY IDENTICAL HUGE STRING> When you add in line breaks it gets impossible to "eyeball" the error message and know what's going wrong. It also breaks up the format of the output report with miles of strings, possibly including line breaks. I've written some code that fixes this. The output for a failed test with message "HTML Report" is: HTML Report: strings differ at character 22 Expected: ...>Poll:</b> dummy<br>\n<b>Question:</b> Vote for your favor... Actual: ...>Poll:</b> dummy<br>\r\n<b>Question:</b> Vote for your favo... Note that you can tell right off the bat that the problem is a difference in line endings (since my code escapes those). This particular bug was actually impossible for me to track down using the normal failure message, since line endings are invisible. I'd like to contribute the code to JUnit. I'm just not sure where you want to put it. I see three options: 1. Change the behavior of the existing Assert.assertEquals(String, String) (I don't think this would break anybody's tests, and I doubt anyone has written code that depends on the actual format of the string error messages. I could be wrong, of course.) 2. Add a new assertEqualsDiff to class Assert (This would mean that the benefit of the new messages would not be given to existing tests without massive test code rewrites.) 3. Make a new DiffTestCase that overrides assertEquals (Same problem as above -- existing test code would need to be rewritten. It's also a sloppy substitute for mixins...) If you guys want the code, let me know, and I'll download the JUnit source and give you a patch. - A P.S. I've attached the current version below. I don't think this is the final version, though -- I want it to be smarter about diffs close to the start and end of the strings. -- Alex Chaffee mailto:al...@jg... jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/ void assertEqualsDiff(String message, String expected, String actual) { if (!expected.equals(actual)) { if (expected.length() < 20 || actual.length() < 20) { assertEquals(message, expected, actual); return; // we'll get an exception, but just in case } int at = strdiffat(actual, expected); String expectedContext = Utils.abbreviate(expected.substring(at - 20), 60); String actualContext = Utils.abbreviate(actual.substring(at - 20), 60); assertTrue(message + ": strings differ at character " + at + "\n" + "Expected: ..." + Utils.jsEscape(expectedContext) + "\n" + " Actual: ..." + Utils.jsEscape(actualContext) + "\n", false); } } /** * returns the index where the strings diverge<p> * strdiff("i am a machine", "i am a robot") -> 7<p> * @return -1 if they are the same * **/ public static int strdiffat(String s1, String s2) { int i; for (i=0; i<s1.length() && i<s2.length(); ++i) { if (s1.charAt(i) != s2.charAt(i)) { break; } } if (i<s2.length() || i<s1.length()) return i; return -1; } for abbreviate() and jsEscape() see http://www.purpletech.com/code/src/com/purpletech/util/Utils.java |
From: Erik M. <em...@ge...> - 2002-02-18 23:13:43
|
Alex, Good stuff! When on the road I get asked for just this bit of functionality a lot. You can go ahead and use SF to submit your patch (http://sourceforge.net/tracker/?group_id=15278&atid=315278) You'll notice a lot of patches there. You greatly increase your odds of getting your patch in by supplying tests and making your code look like the JUnit code. int at= strdiffat(actual, expected); vs. int at = strdiffat(actual, expected); I sort of like the assertEqualsDiff, but that is probably due to my fear that we would break someone's tests. I would feel a lot better about modifying assertEquals if Kent or Erich blessed it. The purpletech license looks okay, and the Util class has a JUnit TestCase :) Not sure how we should handle the external dependency... I see two options, put it in the JUnit CVS or use an Ant task to download it (I like the second). Erik Meade http://junit.org em...@ob... > -----Original Message----- > From: jun...@li... > [mailto:jun...@li...]On Behalf Of > gu...@st... > Sent: Monday, February 18, 2002 10:56 AM > To: jun...@li... > Subject: [Junit-devel] assertEquals: String compare with context diff > > > The method assertEquals(String, String) is very useful, but breaks > down with large strings. The problem is that, if the strings differ > in only a few characters, or start to differ more than a few lines in, > the error message is almost completely useless. > > expected:<HUGE STRING> but was:<NEARLY IDENTICAL HUGE STRING> > > When you add in line breaks it gets impossible to "eyeball" the error > message and know what's going wrong. It also breaks up the format of > the output report with miles of strings, possibly including line > breaks. > > I've written some code that fixes this. The output for a failed test > with message "HTML Report" is: > > HTML Report: strings differ at character 22 > Expected: ...>Poll:</b> dummy<br>\n<b>Question:</b> Vote for your favor... > Actual: ...>Poll:</b> dummy<br>\r\n<b>Question:</b> Vote for > your favo... > > Note that you can tell right off the bat that the problem is a > difference in line endings (since my code escapes those). This > particular bug was actually impossible for me to track down using the > normal failure message, since line endings are invisible. > > I'd like to contribute the code to JUnit. I'm just not sure where you > want to put it. > > I see three options: > > 1. Change the behavior of the existing Assert.assertEquals(String, String) > > (I don't think this would break anybody's tests, and I doubt > anyone has written code that depends on the actual format of > the string error messages. I could be wrong, of course.) > > 2. Add a new assertEqualsDiff to class Assert > > (This would mean that the benefit of the new messages would > not be given to existing tests without massive test code > rewrites.) > > 3. Make a new DiffTestCase that overrides assertEquals > > (Same problem as above -- existing test code would need to be > rewritten. It's also a sloppy substitute for mixins...) > > If you guys want the code, let me know, and I'll download the JUnit > source and give you a patch. > > - A > > P.S. I've attached the current version below. I don't think this is > the final version, though -- I want it to be smarter about diffs close > to the start and end of the strings. > > -- > Alex Chaffee mailto:al...@jg... > jGuru - Java News and FAQs http://www.jguru.com/alex/ > Creator of Gamelan http://www.gamelan.com/ > Founder of Purple Technology http://www.purpletech.com/ > Curator of Stinky Art Collective http://www.stinky.com/ > > > void assertEqualsDiff(String message, String expected, String actual) > { > if (!expected.equals(actual)) { > if (expected.length() < 20 || actual.length() < 20) { > assertEquals(message, expected, actual); > return; // we'll get an exception, but just in case > } > int at = strdiffat(actual, expected); > String expectedContext = > Utils.abbreviate(expected.substring(at - 20), 60); > String actualContext = > Utils.abbreviate(actual.substring(at - 20), 60); > assertTrue(message + ": strings differ at character " + > at + "\n" + > "Expected: ..." + > Utils.jsEscape(expectedContext) + "\n" + > " Actual: ..." + > Utils.jsEscape(actualContext) + "\n", > false); > } > } > > /** > * returns the index where the strings diverge<p> > * strdiff("i am a machine", "i am a robot") -> 7<p> > * @return -1 if they are the same > * > **/ > public static int strdiffat(String s1, String s2) { > int i; > for (i=0; i<s1.length() && i<s2.length(); ++i) { > if (s1.charAt(i) != s2.charAt(i)) { > break; > } > } > if (i<s2.length() || i<s1.length()) > return i; > return -1; > } > > for abbreviate() and jsEscape() see http://www.purpletech.com/code/src/com/purpletech/util/Utils.java _______________________________________________ Junit-devel mailing list Jun...@li... https://lists.sourceforge.net/lists/listinfo/junit-devel |
From: Vladimir B. <vla...@bo...> - 2002-02-19 01:36:07
|
Personally a disagree. The problem is not in how JUnit asserts the strings, but how it displays the result. The solution of a 'display' problem must be solved in the UI/textUI and not in the assertions. In 99.999% of the cases, you won't have problems when asserting strings so proposing a solution that will affect everyone (and confuse some) to solve a rare problem is not the thing to do (imho) Another idea is to have a small UI application were you can paste the result of the failure message and have a visual response where your strings differ. This tool can be stand-alone or integrated into the standard UI without too much hassle. But because the stings must first be printed out before you can copy them, you may have to convert the \n \t \r ... in the asserted strings into something more understandable. just an idea -Vladimir -- Vladimir Bossicard www.bossicard.com |
From: Erik M. <em...@ge...> - 2002-02-19 01:44:02
|
> -----Original Message----- > From: jun...@li... > [mailto:jun...@li...]On Behalf Of Vladimir > Bossicard > Sent: Monday, February 18, 2002 7:34 PM > To: JUnit-Devel > Subject: Re: [Junit-devel] assertEquals: String compare with context > diff > > just an idea > > -Vladimir A pretty good one. Erik Meade http://junit.org em...@ob... |
From: <gu...@st...> - 2002-02-19 06:07:51
|
On Mon, Feb 18, 2002 at 05:34:01PM -0800, Vladimir Bossicard wrote: > Personally a disagree. > > The problem is not in how JUnit asserts the strings, but how it displays > the result. The solution of a 'display' problem must be solved in the > UI/textUI and not in the assertions. You can argue that the assertEquals method should not be responsible for displaying anything to the user. I might agree with you from a design POV. There should be a formatter object, user-configurable, localized, etc. etc. However, the fact is that right now, assertEquals *does* display something to the user, via its Exception message. The question becomes, *what* should it display, in the case where the strings are too long to be meaningful? (My answer is, I think it should intelligently truncate the strings and focus the viewer's attention on the point where they differ.) - A P.S. The junit Ant task has a Formatter object; I could patch this into there as well; however, I think it's better to plug this at the source. -- Alex Chaffee mailto:al...@jg... jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/ |
From: Vladimir B. <vla...@bo...> - 2002-02-19 06:18:58
|
> However, the fact is that right now, assertEquals *does* display > something to the user, via its Exception message. The question > becomes, *what* should it display, in the case where the strings are > too long to be meaningful? The fact is also that is you modify the Assert class, you will have to maintain it even if a better solution (with external formatter) is found. And why not writing your own HugeStringAssert class? This is far the easiest way to achieve what you want without introducing anything into the main release. This solution will be available *immediately* and will not have to wait until JUnit X.Y is released. Then Kent and Erich have to see if they want to develop a formatter/UI application or incorporate your assertXYZ() into the Assert class. This would also teach people how to extend the product by writing their own Assert class. I have replied to many developers that had to test an object but were struggeling with the single assert methods. -Vladimir -- Vladimir Bossicard www.bossicard.com |
From: Stuart R. <stu...@ad...> - 2002-02-19 13:15:32
|
On Tuesday, February 19, 2002, at 06:20 am, Vladimir Bossicard wrote: >> However, the fact is that right now, assertEquals *does* display >> something to the user, via its Exception message. The question >> becomes, *what* should it display, in the case where the strings are >> too long to be meaningful? > > The fact is also that is you modify the Assert class, you will have to > maintain it even if a better solution (with external formatter) is found. > > And why not writing your own HugeStringAssert class? This is far the > easiest way to achieve what you want without introducing anything into > the main release. This solution will be available *immediately* and will > not have to wait until JUnit X.Y is released. Then Kent and Erich have > to see if they want to develop a formatter/UI application or incorporate > your assertXYZ() into the Assert class. +1 to this approach. +0 to the name "HughStringAssert" -1 to the separate UI device - too much like hard work for the poor test executer! Stuart. Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos) Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF ------------------------------------------------------------------------- Stuart Roebuck stu...@ad... Systems Architect Java, XML, MacOS X, XP, etc. ADOLOS <http://www.adolos.com/> |
From: <gu...@st...> - 2002-03-02 17:55:08
|
I've posted my patch to http://www.purpletech.com/junit-patch/ It's a standard patch file -- use patch -p0 < assertEqualsDiff.patch and it should go smoothly. (More detailed instructions on the site.) I'll let the committers decide whether and how to integrate it into JUnit 3.8. In the meantime, anyone who wants to can download it from my site and start using it now. Who do I ping to get an announcement posted to the junit.org home page? Cheers - - Alex -- Alex Chaffee mailto:al...@jg... jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/ |
From: Erik M. <em...@ge...> - 2002-03-02 18:09:25
|
Me. Done. Erik > -----Original Message----- > From: jun...@li... > [mailto:jun...@li...]On Behalf Of > gu...@st... > Sent: Saturday, March 02, 2002 11:55 AM > To: JUnit-Devel > Subject: [Junit-devel] PATCH: assertEquals: String compare with context > diff > > > I've posted my patch to http://www.purpletech.com/junit-patch/ > > It's a standard patch file -- use > patch -p0 < assertEqualsDiff.patch > and it should go smoothly. (More detailed instructions on the site.) > > I'll let the committers decide whether and how to integrate it into > JUnit 3.8. In the meantime, anyone who wants to can download it from > my site and start using it now. > > Who do I ping to get an announcement posted to the junit.org home page? > > Cheers - > > - Alex > > > -- > Alex Chaffee mailto:al...@jg... > jGuru - Java News and FAQs http://www.jguru.com/alex/ > Creator of Gamelan http://www.gamelan.com/ > Founder of Purple Technology http://www.purpletech.com/ > Curator of Stinky Art Collective http://www.stinky.com/ > > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel |
From: Kent B. <ken...@cs...> - 2002-02-21 21:50:43
|
A clever GUI is both more likely to be helpful, less likely to be obstructive, and satisfies our design aesthetic than going into the framework to change the error message. However, we don't have such a GUI at the moment, nor does it seem to be just one step ahead, so I propose than in the spirit of wabi-sabi we summarize the string differences for the moment. The current situation satisfies no one, and it would be good to take a step ahead on this for 3.8. Kent |
From: <gu...@st...> - 2002-02-21 22:54:48
|
On Thu, Feb 21, 2002 at 01:47:50PM -0800, Kent Beck wrote: > A clever GUI is both more likely to be helpful, less likely to be > obstructive, and satisfies our design aesthetic than going into the > framework to change the error message. However, we don't have such a GUI at > the moment, nor does it seem to be just one step ahead, so I propose than in > the spirit of wabi-sabi we summarize the string differences for the moment. > The current situation satisfies no one, and it would be good to take a step > ahead on this for 3.8. > > Kent > Thanks Kent. I've got a patch ready for action, incorporating my strdiff util into the Assert base class. I just need to clean up the license language to make it clear I'm contributing these methods to JUnit with no strings attached. I found the IBM Public License from a pointer on sourceforge but I'm not sure it's correct... Where can I find the JUnit license, to make sure I'm doing this right? - A P.S. As written now, it uses the old style for objects that are null, or objects that are not Strings. Should I also make it use the old style for short strings? (Strings that are <60 chars in length) -- Alex Chaffee mailto:al...@jg... jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/ |
From: <gu...@st...> - 2002-03-07 00:29:43
|
On Wed, Mar 06, 2002 at 03:32:00PM -0800, Kent Beck wrote: > > Where can I find the JUnit license, to make sure I'm doing this right? > > It's in the top level of the distribution. If it is, I couldn't find it anywhere. Also, the word "license" doesn't appear in any of the files in the CVS depot. I think you probably just forgot to check it in at some point. -- Alex Chaffee mailto:al...@jg... jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/ |
From: Erik M. <em...@ge...> - 2002-03-07 02:13:08
|
JUnit is licensed under the Common Public License Version 0.5: http://oss.software.ibm.com/developerworks/oss/license-cpl.html > -----Original Message----- > From: jun...@li... > [mailto:jun...@li...]On Behalf Of > gu...@st... > Sent: Wednesday, March 06, 2002 6:30 PM > To: Kent Beck > Cc: jun...@li... > Subject: [Junit-devel] Re: license > > > On Wed, Mar 06, 2002 at 03:32:00PM -0800, Kent Beck wrote: > > > Where can I find the JUnit license, to make sure I'm doing this right? > > > > It's in the top level of the distribution. > > If it is, I couldn't find it anywhere. Also, the word "license" > doesn't appear in any of the files in the CVS depot. I think you > probably just forgot to check it in at some point. > > -- > Alex Chaffee mailto:al...@jg... |
From: <gu...@st...> - 2002-03-13 14:56:47
|
Oops! Somehow a bogus patched junit.jar made it onto the web site. I just corrected the error. The bogus one was apparently a fully functional version of JUnit 3.7, but four times as big, and with the unpatched version of Assert (though, oddly, containing my new string utility class, which fooled me into thinking it was correct). I've since made a unit test for my web deploy script to stop this from happening again. The version that's up now works fine, knock wood. http://www.purpletech.com/junit-patch/ - A P.S. The patch itself always worked; this was just me building and/or deploying the wrong JAR file somehow. On Mon, Feb 18, 2002 at 08:55:55AM -0800, gu...@st... wrote: > The method assertEquals(String, String) is very useful, but breaks > down with large strings. The problem is that, if the strings differ > in only a few characters, or start to differ more than a few lines in, > the error message is almost completely useless. > > expected:<HUGE STRING> but was:<NEARLY IDENTICAL HUGE STRING> > > When you add in line breaks it gets impossible to "eyeball" the error > message and know what's going wrong. It also breaks up the format of > the output report with miles of strings, possibly including line > breaks. > > I've written some code that fixes this. The output for a failed test > with message "HTML Report" is: > > HTML Report: strings differ at character 22 > Expected: ...>Poll:</b> dummy<br>\n<b>Question:</b> Vote for your favor... > Actual: ...>Poll:</b> dummy<br>\r\n<b>Question:</b> Vote for your favo... > > Note that you can tell right off the bat that the problem is a > difference in line endings (since my code escapes those). This > particular bug was actually impossible for me to track down using the > normal failure message, since line endings are invisible. > > I'd like to contribute the code to JUnit. I'm just not sure where you > want to put it. > > I see three options: > > 1. Change the behavior of the existing Assert.assertEquals(String, String) > > (I don't think this would break anybody's tests, and I doubt > anyone has written code that depends on the actual format of > the string error messages. I could be wrong, of course.) > > 2. Add a new assertEqualsDiff to class Assert > > (This would mean that the benefit of the new messages would > not be given to existing tests without massive test code > rewrites.) > > 3. Make a new DiffTestCase that overrides assertEquals > > (Same problem as above -- existing test code would need to be > rewritten. It's also a sloppy substitute for mixins...) > > If you guys want the code, let me know, and I'll download the JUnit > source and give you a patch. > > - A > > P.S. I've attached the current version below. I don't think this is > the final version, though -- I want it to be smarter about diffs close > to the start and end of the strings. > > -- > Alex Chaffee mailto:al...@jg... > jGuru - Java News and FAQs http://www.jguru.com/alex/ > Creator of Gamelan http://www.gamelan.com/ > Founder of Purple Technology http://www.purpletech.com/ > Curator of Stinky Art Collective http://www.stinky.com/ > > > void assertEqualsDiff(String message, String expected, String actual) > { > if (!expected.equals(actual)) { > if (expected.length() < 20 || actual.length() < 20) { > assertEquals(message, expected, actual); > return; // we'll get an exception, but just in case > } > int at = strdiffat(actual, expected); > String expectedContext = > Utils.abbreviate(expected.substring(at - 20), 60); > String actualContext = > Utils.abbreviate(actual.substring(at - 20), 60); > assertTrue(message + ": strings differ at character " + at + "\n" + > "Expected: ..." + Utils.jsEscape(expectedContext) + "\n" + > " Actual: ..." + Utils.jsEscape(actualContext) + "\n", > false); > } > } > > /** > * returns the index where the strings diverge<p> > * strdiff("i am a machine", "i am a robot") -> 7<p> > * @return -1 if they are the same > * > **/ > public static int strdiffat(String s1, String s2) { > int i; > for (i=0; i<s1.length() && i<s2.length(); ++i) { > if (s1.charAt(i) != s2.charAt(i)) { > break; > } > } > if (i<s2.length() || i<s1.length()) > return i; > return -1; > } > > for abbreviate() and jsEscape() see http://www.purpletech.com/code/src/com/purpletech/util/Utils.java > > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel -- Alex Chaffee mailto:al...@jg... jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/ |