This is for a desktop GUI application. I need to store my Java classes and JUnit test classes in two separate folders.
How do I go about doing this in Eclipse, rather what is the best approach to do this?
Create two different projects for swings and test cases. Because I feel that it separates the functionality. Don't write anything under default package, as it is said that its not a good practice.
I like mavens folder structure. src/main/java and src/test/java
Then use the same package names in each folder so the unit test class has access to the variables in your class.
in eclipse it can generate a unit test class for you. definitely use different folders though so when you package your code you can easily leave the tests out.
Related
I'm new to unit testing.
I have a existing maven based project, now my management has asked me to create unit test for all the classes.
So is there any way to automatically generate test classes based on my src package structure.
What I mean is rather than manually replicating the package structure is it possible to automatically generate Test classes.
For instance, if I have com.company.HelloWorld in src folder can it automatically generate com.company.HelloWorldTest in test folder.
Note: actually I do not want the code to be generated automatically just wanted the package structure and test classes to be created within which I can write my own code.
I do not know a way to create unit tests automatically. Actually it is almost impossible. Unit test is a class, i.e. code that is typically written by human.
You want to create templates for unit tests. But if you do this automatically they will be empty and there is no way then to prevent you from running empty test cases and be happy that all tests succeed.
So, taking in consideration that you have a tiny project (45 classes) I'd recommend you to create your tests manually. You can however use Eclipse plugin that helps you to create empty test case in correct package.
I'm writing tests for plug-ins, now is my question is it better to make an apart test source folder for the test classes or can I put them all in the normal source directory?
Because I think it is better to split the functionality classes from the tests classes. So there can't be mistakes. Also if someones deploy the plug-in into the system, all the classes will deploy except the test classes. Am I right?
Keep the test classes in a separate source folder.
You are right. It's best to have them in a separate source folder. You do not want to deploy these classes when you deploy your plug-in, so it's best to keep them separate. You also don't want these test classes in the same mix when you generate documentation.
I am not so aware of the java project structure. I have few selenium tests which I want to write in java. So I have chosen eclipse as my editor. Here I wan to create a new java project with proper folder structure as I am planning to add few more java classes in future.
Please let me know how to create an idea java project in eclipse. I have seen people create something like com.org.project_name etc and then src , resources directories inside that.
I am not able to make any sense out of those. Please explain.
The software project management tool Apache Maven recommends, uses and expects a common directory layout that can be considered as best practise.
An overview can be found here: Introduction to the Standard Directory Layout
In Java you can create packages. Simply said packages are folders that contain classes.
The statement import java.net.Socket means: from the folder java/net import the class named Socket.
The statement package myApplication.util.SuperCounter means that the class SuperCounter can be found under myApplication/util folder.
Packages are an easy way to organize your work. Because in a big project you will have class name collisions (i.e. classes that use the same name). With packages you can avoid it.
Also Java supports default (private, public, protected). Default methods, attributes, classes can only be seen by elements in the same package!
Eclipse should create the proper folders for you...here is an example
http://www.wikihow.com/Create-a-New-Java-Project-in-Eclipse
If you want to have a Java Project then go to File -> New -> Java Project.
If its web application then, select Dynamic Web Project.
These will automatically create the required structures.
In Java you work in packages, which define the scope of your classes, and is basically the only thing you should really be concentrating on in the beginning. There's a good article on the subject here - http://docs.oracle.com/javase/tutorial/java/package/packages.html
In TDD(Test Driven Development) development process, how to deal with the test data?
Assumption that a scenario, parse a log file to get the needed column. For a strong test, How do I prepare the test data? And is it properly for me locate such files to the test class files?
Maven, for example, uses a convention for folder structures that takes care of test data:
src
main
java <-- java source files of main application
resources <-- resource files for application (logger config, etc)
test
java <-- test suites and classes
resources <-- additional resources for testing
If you use maven for building, you'll want to place the test resources in the right folder, if your building with something different, you may want to use this structure as it is more than just a maven convention, to my opinion it's close to 'best practise'.
Another option is to mock out your data, eliminating any dependency on external sources. This way it's easy to test various data conditions without having to have multiple instances of external test data. I then generally use full-fledged integration tests for lightweight smoke testing.
Hard code them in the tests so that they are close to the tests that use them, making the test more readable.
Create the test data from a real log file. Write a list of the tests intended to be written, tackle them one by one and tick them off once they pass.
getClass().getClassLoader().getResourceAsStream("....xml");
inside the test worked for me. But
getClass().getResourceAsStream("....xml");
didn't worked.
Don't know why but maybe it helps some others.
When my test data must be an external file - a situation I try to avoid, but can't always - I put it into a reserved test-data directory at the same level as my project, and use getClass().getClassLoader().getResourceAsStream(path) to read it. The test-data directory isn't a requirement, just a convenience. But try to avoid needing to do this; as #philippe points out, it's almost always nicer to have the values hard-coded in the tests, right where you can see them.
I'm new to unit testing using nunit (and Java development in general). When creating unit tests for private methods on classes, it looks as though the test file must be in the same package as the class being tested. What is the typical way of avoiding exporting the APIs of the unit tests? Can I make the classes/test methods package-protected? Or do developers typically have a separate build for release that excludes unit test files?
I can tell IntelliJ or Ant not to package JUnit tests in the deployment. I have tests in a separate directory from the source code, which is what makes it possible.
Don't mingle source and test classes together. Keep them separate to make it easier for the tool/script you use to deploy.
The test file does not necessarily have to be in the same package as the class being tested. In fact, it is a good practice to have the test files in a completely separate package, allowing them to test the public API without being concerned with package-level implementation details.
Alternately, you can set up your build script (e.g. Nant) to ignore files containing "Test" when you build your release executable.
Personally my approach is only to test exposed functionality, so you end up testing well encapsulated parts only.
This usually leads my design to contain small classes with well defined functionality, which are easier to test.
Generally, when unit testing you shouldn't be concerned with the internals of what you're testing, so I find this is the best way to approach it.
I also agree it's best to seperate test and production code.
Keep test source code out of application source code. In general, only test exposed functionality. If you really need to test private behavior, create a test object that extends the real object and allows publec access to the private behavior.
I think it's a mistake to move your test code out of the package of the CUT (Class Under Test). At some point you may want to test a protected method or class, and having your test code in another package makes that hard or impossible.
A better solution is to create a separate directory for your test code that simply mirrors the package structure of your production code. Here's what I do:
src/main/java/com/example/Foo.java
src/test/java/com/example/FooTest.java
Then your build script can very simply ignore src/test/** when it comes time for packaging and deployment.