Develop Reference

How to skip Junit for some java classes using mavan?

I have some classes for which I dont have to write junit classes so I want to skip Junit for some Java classes and want to increase Junit code coverage using Maven. For example, I have placed all Java classes in com.test.xxx package so that I can tell them all classes are to be skipped.

You can use a #Disabled Tag to disable a specific Test. If you just have empty test classes, for whatever reason. Delete them.
If you want to fake code coverage for whatever reason, you can create tests and call your services inside the tests, but do not add any assertations... However this is extremly bad practice and I cant really suggest it to you.

How do I find out what testcases are in my source code and can I categorize them?

I'm working with a large project with 50,000 source files about 5000 tests spread over 2000 classes. These are mostly JUnit 3 with a smattering of JUnit 4. These tests are run on a frequent (daily or weekly) basis from batch files to ensure the product is working and not suffering from regressions or other issues.
I want to enumerate through the source or class files and produce a list of classes and methods that represent the test cases in the project. I can compare this list to determine which tests are not being run by the batch files.
Is there any simple way to do this such as functionality in JUnit? Or is there functionality in JUnit I could programatically drive to get it, e.g. to scan a dir full of class files and figure out which are tests. I realise that I could write code to individually load each class and start examining it for certain characteristics but if something exists I'd like to be able to use it.
The second part of the question, is there any commonly used way to to annotate tests? If I could annotate tests I could potentially filter them and generate batch files on the fly that run them according to the filter criteria. e.g. run all tests which need a network connection, run all tests that use subsystem A and so on.
Is there anything which would help me do this? I realise I could roll my own annotation with a comma separated list of values or something, but perhaps this sort of thing has been formalised and there are tools that work with it.

Tests are classes that extend TestCase (in case of JUnit 3) or annotated as #Test (in case of JUnit 4). So it is not a problem to do either using IDE or programmatically: write program that finds all *class files recursively into your classes folder(s) and tests whether class extends TestCase or is annotated with #Test.

Set up Java Swing project w/ JUnit/Eclipse

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.

How to deal with the test data in Junit?

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.

Creating nunit tests without exporting them with the api

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.