How to use getTimeout method of org.junit.runners.model.TestTimedOutException class

The IT.java suffix is a convention used by the Maven Failsafe Plugin. All classes in the test directory that have the suffix IT are executed by this plugin in the integragion-test phase. (Tests with suffix Test are exectued by the Maven Surefire Plugin in the test phase.)

When loading the Properties from a Class in the package com.al.common.email.templates you can use

Properties prop = new Properties();
InputStream in = getClass().getResourceAsStream("foo.properties");
prop.load(in);
in.close();

(Add all the necessary exception handling).

If your class is not in that package, you need to aquire the InputStream slightly differently:

InputStream in = 
 getClass().getResourceAsStream("/com/al/common/email/templates/foo.properties");

Relative paths (those without a leading '/') in getResource()/getResourceAsStream() mean that the resource will be searched relative to the directory which represents the package the class is in.

Using java.lang.String.class.getResource("foo.txt") would search for the (inexistent) file /java/lang/String/foo.txt on the classpath.

Using an absolute path (one that starts with '/') means that the current package is ignored.

In your project's preferences, you must set the compiler --source option to 1.7 and --target option to 1.7 also. There are dedicated option boxes for that.

Right-click on the project. Choose Properties. Choose Java Compiler on the left. Choose 1.7 for the Compiler Compliance level. If the 2 drop-downs below that aren't 1.7, uncheck Use default compliance settings and set those to 1.7.

Annotate the exception property with @JvmField:

@Rule
@JvmField
var exception = ExpectedException.none()

I've used JUnit for doing a lot of integration testing. Integration testing can, of course, mean many different things. For more system level integration tests, I prefer to let scripts drive my testing process from outside.

Here's an approach that works well for me for applications that use http and databases and I want to verify the whole stack:

1. Use Hypersonic or H2 in in-memory mode as a replacement for the database (this works best for ORMs)
2. Initialize the database in @BeforeSuite or equivalent (again: easiest with ORMs)
3. Use Jetty to start an in-process web server.
4. @Before each test, clear the database and initialize with the necessary data
5. Use JWebUnit to execute HTTP requests towards Jetty

This gives you integration tests that can run without any setup of database or application server and that exercises the stack from http down. Since it has no dependencies on external resources, this test runs fine on the build server.

Here some of the code I use:

@BeforeClass
public static void startServer() throws Exception {
    System.setProperty("hibernate.hbm2ddl.auto", "create");
    System.setProperty("hibernate.dialect", "...");
    DriverManagerDataSource dataSource = new DriverManagerDataSource();
    dataSource.setJdbcUrl("jdbc:hsqldb:mem:mytest");
    new org.mortbay.jetty.plus.naming.Resource(
             "jdbc/primaryDs", dataSource);


    Server server = new Server(0);
    WebAppContext webAppContext = new WebAppContext("src/main/webapp", "/");
    server.addHandler(webAppContext);
    server.start();
    webServerPort = server.getConnectors()[0].getLocalPort();
}

// From JWebUnit
private WebTestCase tester = new WebTestCase();

@Before
public void createTestContext() {
    tester.getTestContext().setBaseUrl("http://localhost:" + webServerPort + "/");
    dao.deleteAll(dao.find(Product.class));
    dao.flushChanges();
}

@Test
public void createNewProduct() throws Exception {
    String productName = uniqueName("product");
    int price = 54222;

    tester.beginAt("/products/new.html");
    tester.setTextField("productName", productName);
    tester.setTextField("price", Integer.toString(price));
    tester.submit("Create");

    Collection<Product> products = dao.find(Product.class);
    assertEquals(1, products.size());
    Product product = products.iterator().next();
    assertEquals(productName, product.getProductName());
    assertEquals(price, product.getPrice());
}

For those who'd like to know more, I've written an article about Embedded Integration Tests with Jetty and JWebUnit on Java.net.

By default Maven uses the following naming conventions when looking for tests to run:

• Test*
• *Test
• *Tests (has been added in Maven Surefire Plugin 2.20)
• *TestCase

If your test class doesn't follow these conventions you should rename it or configure Maven Surefire Plugin to use another pattern for test classes.

I know it's a bit late to answer this question, and maybe you already found the solution, but I'm posting the solution I found (after I googled a lot) so it may help a little:

1. Put log4j.properties under WEB-INF\classes of the project as mentioned previously in this thread.
2. Put log4j-xx.jar under WEB-INF\lib
3. Test if log4j was loaded: add -Dlog4j.debug @ the end of your java options of tomcat

Hope this will help.

rgds

The distinction becomes clear when you have more than one test method in a class.

A @ClassRule has its before() method run before any of the test methods. Then all the test methods are run, and finally the rule's after() method. So if you have five test methods in a class, before() and after() will still only get run once each.

@ClassRule applies to a static method, and so has all the limitations inherent in that.

A @Rule causes tests to be run via the rule's apply() method, which can do things before and after the target method is run. If you have five test methods, the rule's apply() is called five times, as a wrapper around each method.

Use @ClassRule to set up something that can be reused by all the test methods, if you can achieve that in a static method.

Use @Rule to set up something that needs to be created a new, or reset, for each test method.

Is there something like mocking a variable? I would call that re-assign. I don't think EasyMock or PowerMock will give you an easy way to re-assign a static final field (it sounds like a strange use-case).

If you want to do that there probably is something wrong with your design: avoid static final (or more commonly global constants) if you know a variable may have another value, even for test purpose.

Anyways, you can achieve that using reflection (from: Using reflection to change static final File.separatorChar for unit testing?):

static void setFinalStatic(Field field, Object newValue) throws Exception {
    field.setAccessible(true);

    // remove final modifier from field
    Field modifiersField = Field.class.getDeclaredField("modifiers");
    modifiersField.setAccessible(true);
    modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL);

    field.set(null, newValue);
}

Use it as follows:

setFinalStatic(MyClass.class.getField("myField"), "newValue"); // For a String

Don't forget to reset the field to its original value when tearing down.