Archive for December, 2009

Are tests of service methods that rely on database access unit tests?

December 29, 2009

It is often argued whether tests that need a database should be called “unit tests”. Most often the answer is “No, these are database integration tests”. My opinion is – “Yes”.

The whole problem is routed in the fact that service methods depend on data access. If an application is designed properly the data access is abstracted in the DAO layer, so the code is testable.

So why is it proper to call these tests “unit tests”. Because service methods (units) are tested. These methods have a dependency on the Data Access layer, which in turn depends on a database. Now, a purely unit-testing approach would be to mock the dependency – the DAO in this case. This mock should be fairly complex in order to behave as expected. So why creating a complex mock, if you can instead use an in-memory database (HSQLDB/Derby/JavaDB), which can be realized as a mock of the runtime setup.

Here’s why this is not a database integration testing – you are not testing whether your application integrates with a real database. You test the business operations that rely on database operations. But the way these operations are performed is practically mocked (though not in the standard sense)

In regard to build speed concerns – in-memory databases are (logically) very fast. This alone can reduce the amount of time for running the tests to levels low enough.

Advertisements

JAXB: javax.xml.bind.UnmarshalException: unexpected element

December 18, 2009

JAXB: [javax.xml.bind.UnmarshalException: unexpected element (uri:"http://mynamespace/", local:"entity"). Expected elements are ({}entity)]

The following exception broadly means that an element encountered during unmarshallization isn’t found in the JAXB Context.
The details, however point us elsewhere – the element IS in the context, but it exists there without a namespace.
The first thing to do is check whether our @XmlType / @XmlRootElement define a namespace. And they do.
Finally, there is @XmlSchema annotation that defines an attribute called elementFormDefault. In order to put the elements together with their namespaces, this atribute must be set to javax.xml.bind.annotation.XmlNsForm.QUALIFIED. This annotation should be defined in package-info.java

Hibernate: could not locate named parameter

December 18, 2009

Today I got this exception. Pretty obvious? Well, no. The named parameter IS there. (Sidenote: this exception generally means that when trying to call setParameter(..) with a certain param name, that name is not found in the query, in the form :paramName)
The query is generated dynamically on different entities. And it works, except for one.
And that “one” turned out NOT to be an @Entity. But Hibernate wasn’t too helpful on that.

So to summarize, when you attempt to make a query on a non-entity, Hibernate will not complain that it is not an entity – it will complain about other things.

Custom exceptions thrown from service layer with spring transaction support

December 6, 2009

The title explains the preconditions:

  • spring beans (conforming to an interface), using @Transactional (or <tx:advice>)
  • custom exception is thrown from within the service methods
  • There is a little trick – if the exception is unckecked (extends RuntimeException), it is being wrapped in a TransactionRollbackException.

    So if you are expecting a custom exception (in a unit test, for example), it must be checked. Which is completely logical, of course, but people are often tempted by the easy usage of unchecked exceptions (no explicit need to declare or catch them).

A month on Stackoverflow

December 4, 2009

Stackoverflow is a programming Q & A site. There are all sorts of developers’ topics can be asked there, and most of them get answered pretty quickly. I won’t go into details about Stackoverflow itself, but rather my first month there.

The result of my first month there is 3200 reputation points, top ranks (during the last 30 days) in the tags: java, hibernate, spring, jsf, but, more importantly – more knowledge. Yes, I’ve asked only 5 questions, but in the process of answering questions, and seeing others’ answers, one gains better knowledge and understanding on various topics. Answering is both a race for a better and more complete answer, and a brainstorming on the exact context of the question. When providing an answer to a non-trivial question, you perfect yourself in quick problem-solving.

As for the questions asked – most of them can be answered by a simple google search. Most of the people are too lazy to read tutorials, and ask stupid questions instead. Unfortunately, the answers to the easiest questions let you gain more reputation, and the answers to the complex questions – less. Simply because few people are digging into the complex questions, let alone the complex answers.

So as a conclusion of my first month there – Stackoverflow is one of the best places for developers to go whenever bored, so that they can feed both their egos and heads a little.