Author: Saharsh




In generic type declaration the wildcard ‘?’ and the ‘super’ keyword are NOT allowed; following will NOT compile:
public <? super T> void go(List<T> a) {  }

However, this is perfectly valid:
public static <T extends Comparable<? super T>> void sort(List<T> list)

The type has to implement comparable of itself or its superclass. So consider java.util.Date. It implements Comparable<Date>. But what about java.sql.Date? It implements Comparable<java.util.Date> as well (java.sql.Date extends java.util.Date).
Without the super signature, SortedList would not be able accept the type of java.sql.Date, because it doesn’t implement a Comparable of itself, but rather of a super class of itself.

Extends – tells you what you can get out of a class (you get at least this, perhaps a subclass). e.g.,
public static <T> void copy(List<T> dest, List<? extends T> src)

Super – tells you what you can put into the class (at most this, perhaps a superclass).


Integration Tests

What is an integration test

Sometimes there is not a clear distinction on what is an integration test and what is a unit test.

Basic rule of thumb is that if

  1. a test uses the database
  2. a test uses the network
  3. a test uses an external system (e.g. a queue or a mail server)
  4. a test reads/writes files or performs other I/O

…then it is an integration test and not a unit test. Below is brief comparison between the two. (more…)

Resource Loading

Use either of below way given a) directory is on the classpath. b) class loading the resource is loaded by the same classloader.

1.    From ClassLoader perspective, all paths are “absolute” already – there’s no context from which they could be relative. Therefore, no need for a leading slash.
InputStream in = this.getClass().getClassLoader().getResourceAsStream(“SomeTextFile.txt”);

2.    From Class perspective, the path is relative to the package of the class unless a leading slash is included, so if we don’t want to use the current package, include a slash like this:
InputStream in = this.getClass().getResourceAsStream(“/SomeTextFile.txt”);

UML Notations

Aggregation is a special type of association used to model a “whole to its parts” relationship. In basic aggregation relationships, the lifecycle of a part class is independent from the whole class’s lifecycle. For example, we can think of Car as a whole entity and Car Wheel as part of the overall Car. The wheel can be created weeks ahead of time, and it can sit in a warehouse before being placed on a car during assembly. In this example, the Wheel class’s instance clearly lives independently of the Car class’s instance. However, there are times when the part class’s lifecycle is not independent from that of the whole class — this is called composition aggregation. Consider, for example, the relationship of a company to its departments. Both Company and Departments are modeled as classes, and a department cannot exist before a company exists. Here the Department class’s instance is dependent upon the existence of the Company class’s instance. (more…)

Junit with Spring

Key Points

  • If test case class “extends TestCase”, it’s a JUnit 3.x test class. JUnit 4.x classes don’t need to inherit from anything, they use @Test annotations.
  • Ways to a make a test class Spring4 test:
    Option 1
    Extend AbstractTransactionalJUnit4SpringContextTests – Abstract base test class which integrates the Spring TestContext Framework with explicit ApplicationContext testing support in a JUnit environment.

    Option 2
    Add these annotations to your test class:

    @TestExecutionListeners( { DependencyInjectionTestExecutionListener.class,
    DirtiesContextTestExecutionListener.class })

TestExecutionListeners are a way to externalize reusable code that instruments your tests.

As such, if you implement a TestExecutionListener you can reuse it across test class hierarchies and potentially across projects, depending on your needs.

On the flip side, a @BeforeClass method can naturally only be used within a single test class hierarchy.

Note, however, that JUnit also supports Rules: if you implement org.junit.rules.TestRule you can declare it as a @ClassRule to achieve the same thing… with the added benefit that a JUnit Rule can be reused just like a Spring TestExecutionListener.

So it really depends on your use case. If you only need to use the “before class” functionality in a single test class or a single test class hierarchy, then you’d be better off going the simple route of just implementing a @BeforeClass method. However, if you foresee that you will need the “before class” functionality in different test class hierarchies or across projects, you should consider implementing a custom TestExecutionListener or JUnit Rule.

The benefit of a Spring TestExecutionListener over a JUnit Rule is that a TestExecutionListener has access to the TestContext and therefore access to the Spring ApplicationContext which a JUnit Rule would not have access to. Furthermore, a TestExecutionListener can be automatically discovered and ordered.

  • Spring automatically wraps test methods in rollback-only transactions when test-case class is annotated with @Transactional. This has certain benefits: you won’t corrupt your database during the test and each test works on the same data, so you are not introducing inter-test dependencies.