Thread: [java-gnome-hackers] Failed tests run + LoremIpsum class location
Brought to you by:
afcowie
From: Sarah L. <xa...@gm...> - 2012-08-10 09:07:29
|
Heya all On the request of the AfC I ran the unit tests and got 5 failures + 5 errors. However for them to run I had to add the directory `doc/examples` as a source directory. the class textview.LoremIpsum was used in 2 tests and is present in there. Why ?! I fail to see the point to set it there when needed in the tests. Kinda defeats the point of being a class for tests or examples, as it seems to be used by both. I think it should be relocated. Below are the unit tests results. I do use the IDE netbeans here. Number of tests seem to want to write to a directory that does not exist, and thus error out.. 2 silly ones that I am not quite sure of, getting Login/Logoff instead of Hello/Goodbye. Anyway I hope this output is useful at least. Kind Regards, Thijs Leibbrand Testsuite: UnitTests Tests run: 267, Failures: 5, Errors: 5, Time elapsed: 11.01 sec Testcase: testInitialization(org.freedesktop.bindings.ValidateInternationalization): Caused an ERROR The supplied locale base dir "tmp/locale" is not found org.freedesktop.bindings.FatalError: The supplied locale base dir "tmp/locale" is not found at org.freedesktop.bindings.Internationalization.init(Internationalization.java:550) at org.freedesktop.bindings.ValidateInternationalization.testInitialization(ValidateInternationalization.java:83) Testcase: testTranslation(org.freedesktop.bindings.ValidateInternationalization): FAILED expected:<[Hello]> but was:<[login]> junit.framework.ComparisonFailure: expected:<[Hello]> but was:<[login]> at org.freedesktop.bindings.ValidateInternationalization.testTranslation(ValidateInternationalization.java:87) Testcase: testStaticWrapper(org.freedesktop.bindings.ValidateInternationalization): FAILED expected:<[Goodbye]> but was:<[logoff]> junit.framework.ComparisonFailure: expected:<[Goodbye]> but was:<[logoff]> at org.freedesktop.bindings.ValidateInternationalization.testStaticWrapper(ValidateInternationalization.java:95) Testcase: testUsingMimeDataViaPattern(org.freedesktop.cairo.ValidateCairoInternals): Caused an ERROR You cannot write to file tmp/tests/org/freedesktop/cairo/MimeType2.svg java.io.IOException: You cannot write to file tmp/tests/org/freedesktop/cairo/MimeType2.svg at org.freedesktop.cairo.SvgSurface.<init>(SvgSurface.java:80) at org.freedesktop.cairo.ValidateCairoInternals.testUsingMimeDataViaPattern(ValidateCairoInternals.java:195) Testcase: testUsingMimeDataExplicit(org.freedesktop.cairo.ValidateCairoInternals): Caused an ERROR You cannot write to file tmp/tests/org/freedesktop/cairo/MimeType1.svg java.io.IOException: You cannot write to file tmp/tests/org/freedesktop/cairo/MimeType1.svg at org.freedesktop.cairo.SvgSurface.<init>(SvgSurface.java:80) at org.freedesktop.cairo.ValidateCairoInternals.testUsingMimeDataExplicit(ValidateCairoInternals.java:132) Testcase: testCovertCoordinatesRoundTrip(org.gnome.gtk.ValidateTextViewBorderWindows): FAILED null junit.framework.AssertionFailedError at org.gnome.gtk.ValidateTextViewBorderWindows.testCovertCoordinatesRoundTrip(ValidateTextViewBorderWindows.java:103) Testcase: testWidthAndHeightNormalization(org.gnome.pango.ValidatePangoTextRendering): Caused an ERROR Cairo reports it cannot open tmp/tests/org/gnome/pango/ValidatePangoTextRendering.pdf for writing java.io.IOException: Cairo reports it cannot open tmp/tests/org/gnome/pango/ValidatePangoTextRendering.pdf for writing at org.freedesktop.cairo.PdfSurface.<init>(PdfSurface.java:101) at org.gnome.pango.ValidatePangoTextRendering.testWidthAndHeightNormalization(ValidatePangoTextRendering.java:111) Testcase: testListAllDictionaries(org.freedesktop.enchant.ValidateEnchantInternals): FAILED Needed to find at least "en" as a dictionary! junit.framework.AssertionFailedError: Needed to find at least "en" as a dictionary! at org.freedesktop.enchant.ValidateEnchantInternals.testListAllDictionaries(ValidateEnchantInternals.java:57) Testcase: testDictionaryKnownToExist(org.freedesktop.enchant.ValidateEnchantInternals): FAILED null junit.framework.AssertionFailedError at org.freedesktop.enchant.ValidateEnchantInternals.testDictionaryKnownToExist(ValidateEnchantInternals.java:64) Testcase: testHandleRendering(org.gnome.rsvg.ValidateVectorIllustrations): Caused an ERROR You cannot write to file tmp/tests/org/gnome/rsvg/Linux_Tux.png java.io.IOException: You cannot write to file tmp/tests/org/gnome/rsvg/Linux_Tux.png at org.freedesktop.cairo.Surface.writeToPNG(Surface.java:118) at org.gnome.rsvg.ValidateVectorIllustrations.testHandleRendering(ValidateVectorIllustrations.java:110) Test UnitTests FAILED test: Deleting: /tmp/TEST-UnitTests.xml BUILD SUCCESSFUL (total time: 17 seconds) |
From: Andrew C. <an...@op...> - 2012-08-12 10:35:33
|
On Fri, 2012-08-10 at 11:07 +0200, Sarah Leibbrand wrote: > Below are the unit tests results. Thanks. I'm getting similar failures, but what's driving me nuts is that they are appearing and not appearing depending on whether I run from Eclipse, or from command line. Worse, at least one test when run individually passes, but when run in the suite fails. My initial guess is that something different is happening in the class loader, but I can't even begin to guess what that might be. AfC Sydney |
From: Andrew C. <an...@op...> - 2012-08-12 23:24:52
|
On Fri, 2012-08-10 at 11:07 +0200, Sarah Leibbrand wrote: > `doc/examples` as a source directory. the class textview.LoremIpsum > was used in 2 tests and is present in there. Why ?! I fail to see the > point to set it there when needed in the tests. Hm. Well, it's not part of the unit tests. The constant text there _is_ used in the Snapshot code that generates images for the API documentation. Anyway, I'd just add doc/examples/ as one of the source trees in your IDE's project. `make test` does the right thing. AfC Sydney |
From: Andrew C. <an...@op...> - 2012-08-12 23:28:35
|
On Fri, 2012-08-10 at 11:07 +0200, Sarah Leibbrand wrote: > Number of tests seem to want to write to a directory that does not > exist, and thus error out.. Ah. Yeah, that makes sense; you need to have run `make test` at least once before testing from your IDE. That will compile the message catalogue to tmp/locale/en_US/LC_MESSAGES/unittest.mo. > 2 silly ones that I am not quite sure of, getting Login/Logoff > instead of Hello/Goodbye. That one is starting to get on my nerves. I've tried running ValidateInternationalization as a test by itself and the test case *passes*. I run it in as the UnitTests suite, and it *fails*. I don't know if anyone has any time to look at this, but Vreixo? Serkan? Guillaume? I sure could use your help on this one. AfC Sydney |
From: Andrew C. <an...@op...> - 2012-08-13 00:53:40
|
On Mon, 2012-08-13 at 09:28 +1000, Andrew Cowie wrote: > That one is starting to get on my nerves. I've tried running > ValidateInternationalization as a test by itself and the test case > *passes*. > > I run it in as the UnitTests suite, and it *fails*. Ok, I've made some tentative progress. The relevant commit message: Force static initalizers and/or library initialization code in setUp() Move initializers, being run once in an initial test case, to a setUp() block. I'm a bit vague as to why this is necessary; it would seem that JUnit or Java 7 is being stricter about its classloading, so we need to force the static initializers to run every test. This is somewhat surprising, but seems a workaround. It's more "correct" JUnit in any event. Go figure. Anyway, the test suite is passing for me now, although I also had to do === modified file 'tests/bindings/org/gnome/gtk/ValidateEntry.java' --- tests/bindings/org/gnome/gtk/ValidateEntry.java 2010-05-14 23:50:09 +0000 +++ tests/bindings/org/gnome/gtk/ValidateEntry.java 2012-08-12 23:12:22 +0000 @@ -26,7 +26,7 @@ */ public class ValidateEntry extends GraphicalTestCase { - public final void testEntryIcon() { + public final void skipEntryIcon() { final Entry entry; entry = new Entry(); because that test depends on GTK 3.4.4 which has the fix for https://bugzilla.gnome.org/show_bug.cgi?id=679537 which I don't have at the moment. Should I commit that to 'mainline'? Doesn't seem so, but you'll need it... AfC Sydney |
From: Andrew C. <an...@op...> - 2012-08-13 23:19:37
|
On Mon, 2012-08-13 at 17:14 +0200, Sarah Leibbrand wrote: > Ok so I ran the `make test` command and got it down to 3 errors within > 2 test cases. > It is kinda silly but my Enchant library doesn't know the 'en' > dictionary. Instead it finds 6 en_XX (e.g. en_GB) dictionaries. Hm. I think that must have to do with what back ends are actually installed on the system. For whatever reason I have an "en" (in addition to "en_CA", "en_GB", etc). - if (tag.equals("en")) { + if (tag.equals("en") || tag.startsWith("en_")) { Just change this to if (tag.startsWith("en")) { should cover all the bases. But before we change - result = Enchant.existsDictionary("en"); + result = Enchant.existsDictionary("en") || Enchant.existsDictionary("en_GB") || Enchant.existsDictionary("en_US"); I'd really like to know why you're not finding "en". It's supposed to be provided by something if there is an English dictionary present. And as for this test case, the point was "a dictionary known to exist" and asking for four options like that is messy. If we *do* have to do that, then it should probably be in a helper function like: result = Enchant.existsDictionary("en"); if (result != null) { return result; } result = Enchant.existsDictionary("en_GB"); if (result != null) { return result; } ... fail("Known good dictionary not found"); Still want to know why I have an "en" and you don't. AfC |