If you're doing things differently because you're doing a unit test you're defeating the purpose of a unit test. A unit test is supposed to perform exactly like production would (except for the setup and teardown of any necessary data and such you need....but that is included in the JUnit test itself and not your code).
However, if you truly do have a good reason for this I'd look at the stack and see if JUnit is there.
First of all, this a probably not a good idea. You should be unit testing the actual production code, not slightly different code.
If you really want to do this, you could look at the stacktrace, but since you are changing your program for this anyway, you might just as well introduce a new static boolean field isUnitTesting in your code, and have JUnit set this to true. Keep it simple.
It might be a good idea if you want to programmatically decide which "profile" to run. Think of Spring Profiles for configuration. Inside an integration tests you might want to test against a different database.
Here is the tested code that works
public static boolean isJUnitTest() {
for (StackTraceElement element : Thread.currentThread().getStackTrace()) {
if (element.getClassName().startsWith("org.junit.")) {
return true;
}
}
return false;
}
Lots of people on this thread say that it's a bad idea for code to run slightly differently while under JUnit. I generally agree, but I think there are some exceptions.
For example, I am currently writing INTEGRATION (as opposed to Unit) tests for an app that connects to a DB.
These acceptance tests often need to completely reinitialize the DB with specific test data.
Obviously, I don't want this EVER, EVER to be done on an actual production DB, because that might completely erase valuable production data.
The easiest way to guarantee that this will never happen, is to make it impossible for the code to connect to a production DB when it is running under JUnit. This in turn can be done if, for example, the Factory that generates a connection can tell that it's running under JUnit, and in that case, will return a null connection unless the database we are trying to connect to has a name that is known to be a test database (ex: "testdatabase").
this is not strictly related to the user question, but I'm pretty sure that someone that get there may find it useful.
I use the following approach: expose a package-local constructor that will be used from tests.
e.g.
src/main/java/ApplicationService.java
public class ApplicationService {
private final Integer someInternalObject;
public ApplicationService(String somePublicArgument) throws NumberFormatException {
someInternalObject = Integer.valueOf(somePublicArgument, 16);
}
ApplicationService(Integer someInternalObject) {
this.someInternalObject = someInternalObject;
}
}
src/test/ApplicationServiceTest.Java
public class ApplicationServiceTest {
@Test
public void testSomething() throws Exception {
ApplicationService applicationService = new ApplicationService(0);
}
}
expose it to all tests
not final classes
Extend it in the tests and provide a public constructor for the package-local or protected one.
final classes
Make a public Factory Method in the same package ( within tests ) that will create it using the package-local constructor.
The shortest (least code) solution is to have a global flag that is set when tests are not running. You can then set it once in your main() (or similar entry point) instead of setting it repeatedly in setup methods of all test classes. This will work as long as there is no other way to enter the code (no alternate main).
The second shortest solution is to scan the call stack for junit package like in Janning's answer. This will work as far as junit doesn't hide itself behind another library and an executor.
Dependency injection will work too, but in this case it's just a fancy way to set what's essentially a global flag.