Does it make sense to do unit testing on Java EE applications?

I have heard that Java EE unit testing is much harder than standard Java applications. The testing for my company's application stays at User Acceptance testing. We verify UI and functions behave as they a开发者_JS百科re supposed to. Does it make sense to do unit testing on Java EE applications? If yes, what are some good starting points?

Of course it makes sense.

Let me guess: in the case of your company, when you make a minor change to a central component, I suppose that you'll repeat once and again your User Acceptance Tests. A real PITA, and overboring for a development team, in my opinion.

Unit testing allows you to develop in a consistent way the different layers of your Java EE app (i.e. view, business and model), AND, moreover, it allows you to do regression testing. The magic with regression testing is that in a long life application, this provides you a way to be sure that a new patch, code refactoring, or evolution doesn't break the current system behaviour. And it can be done automatically if you use a continuous integration tool.

So, you can write unit test for business and model layer in a direct way using, as an example, jUnit. And here comes the problem with Unit testing in Java EE apps: What do we do with the view layer?

Well, for the view layer you can use an automated test tool, say Apache jMeter, to check the expected behaviour of your Webapps, check your data validation, your system stability (programing long tests with a regular number of users) and scalability (with increasing and decreasing concurrent users), stress testing, etc. (I know it's not Unit testing, but it can be used in a similar way for regression testing).

I think it's a capital part of every software project, and I invite you to apply it to some of your project, and compare by yourself the final result.

Java EE 6's CDI resource injection was practically made for unit testing; you can swap out @Inject-ed FacesContexts, database resources, and beans for @Alternative beans that have known, predictable behaviour for testing.

It always makes sense to do unit testing on the server. Java EE is not necessarily harder to unit test. A good starting point is the code and the various layers of the application. i.e. start writing unit tests for persistence, then write unit tests for the services, etc....

Testing at the UI level alone is dangerous, because you can have bugs in the lower layer that are either hidden by, or compensated for in, the upper layers MOST of the time. It also means when you experience a problem, you have to first find out whether the problem is in the front end or the back end.

Yeah, Java EE is harder to unit-test. It's also much harder to fix it when you break something and don't notice it for two weeks because you never bothered to write unit tests.

The more complex the application is, the more you need to have a good testing regimen. And since we're talking about Java EE, it's safe to assume that your application is complex.