If your application is doing XML operations and has JUnit tests then the only real dependency there is the dependency to junit.jar. Your application should not need any Eclipse specific libraries on the classpath.
You sound as if you do not have a complete understanding of what the classpath is and how it relates to the compilation and execution of Java code. I highly recommend that you learn how to develop a simple application with a text editor and the command line.
As far as submitting your code, you can compile and package your code into a JAR file, and submit this along with junit.jar and a simple batch file or shell script that will execute the Java virtual machine to run your program.
Another way would be to compile your program, unpackage junit.jar, and package it all together into an Executable Jar file. All of your classpath dependencies will be self contained within the one file and on most operating systems it can be launched as a typical executable.
As others have already stated: nothing wrong with breaking out a separate method to avoid duplication.
However, as others have also stated: you do want each individual test to clearly indicate what it is setting up and what it is asserting.
Test names will help with that enormously and I assume your actual code has more meaningful names than Test1 and Test2.
To make the code of the individual tests more "intelligible" - ie make it clearer what each test is doing just by reading the code of that test, you can break up your helper method into its obvious parts.
Yes, it will "duplicate" what would otherwise be confined to the single helper as you will now have a number of calls in each test when you could do it with one, but it allows you to give more meaningful names to each helper method.
// Arrange
someHelper = MakeSomeDependency(arg1, arg2, arg3);
sut = MakeSomeObjectUnderTest(someHelper);
// Act
sut.DoSomething();
// Assert
AssertCommonAsserts(sut, expectedvalue1, expectedvalue2);
Assert.AreEqual(sut.SomeProperty, expectedValue);
Note: I am not a fan of multiple asserts in a single test, but there are cases when a single "fact" can only be checked by multiple asserts and I can also think of a number of scenarios in which having some "guard" asserts before the actual "fact" being asserted can help in debugging failures.
If you use a language that supports named parameters, you can make your tests even more intelligible by using that feature so the method call doesn't just convey the values used, but also what those values are used for.
// Arrange
someHelper = MakeSomeDependency(
knownNames: arg1,
unknownNames: arg2,
lookingFor: arg3);
sut = MakeSomeObjectUnderTest(someHelper);
// Act
sut.DoSomething();
// Assert
AssertCommonAsserts(
objectUnderTest: sut,
numberOfItemsFound: expectedvalue1,
nameOfItemFound: expectedvalue2);
Assert.AreEqual(sut.SomeProperty, expectedValue);
Best Answer
It is absolutely common practice to have multiple test methods in a class.
JUnit methods are usually invoked via reflection by collecting all methods in a class (or, as you say, in an entire suite), not by a human application programmer choosing methods from a well-defined API. Therefore, there is no point in keeping each individual test class short or readable; people aren't supposed to understand a class that holds unit tests as a cohesive unit in the same the way that a class of production code should be cohesive. Having one class per test just puts unnecessary strain on your file system (dealing with thousands of files in a directory is often non-linearly expensive).