On Wed, Feb 09, 2005 at 10:25:03AM +0100, Jeroen Frijters wrote: > Thomas Zander wrote: > > Hi, Jeroen. Thanks for your reply. > > I've just looked into this; when I delete the config and the > > SimpleTestHarness I get compile errors in (only) 9 tests. > > The following are easy to fix and run correctly with some > > modifications > > (read: removal of the cast): > > gnu/testlet/java/io/FileDescriptor/jdk11.java > > gnu/testlet/java/io/FileReader/jdk11.java > > gnu/testlet/java/io/FileWriter/jdk11.java > > gnu/testlet/java/io/RandomAccessFile/jdk11.java > > > > These are a bit more difficult; but I believe them to be > > broken by design or not usable for a 'java -jar' kind of > > test anyway. > > I'll be more specific: > > These 4 tests each test some socket stuff based completely on the > > assumtion that there is someone (an smtp host) listening on a > > pre-configured host/port. This is quite an assumtion that is not very > > usable in the proposed (portable) test-jar. > > gnu/testlet/java/net/Socket/SocketTest.java > > gnu/testlet/java/net/Socket/jdk12.java > > gnu/testlet/java/net/Socket/jdk13.java > > gnu/testlet/java/net/Socket/jdk14.java > > I don't think they're inherently unusable from a jar, I'd like to see a > gnu.testlet.config version that reads the settings from a properties > file (or whatever) instead of hardcoding them in the auto dance. The way the config settings are shipped is not the issue here; the question where a socket can connect to that is reachable from the testing machine so the test does not fail because of wrong reasons is a bigger problem. And the one I tried to list above. When we solve that issue then we can think about how to config it. I have no idea how to do so; so I'm open to suggestions! > > The following test tests things like being able to open a > > file we ship in mauve (in the same package) and other stuff thats > > really really basic. (like File.seperator) Quite useless to test > > in an environment that is shipped in a jar :-) > > gnu/testlet/java/io/File/jdk11.java > > This is more tricky to handle, but hopefully we can figure out a way to > get this test in as well. When we are actually running this test we already did a 'java -jar' and we found several classes in that jar. Does that not imply that the tests in that class will pass? -- Thomas Zander