DevGrok

Unit testing is very useful for finding bugs in isolated pieces of code and for checking whether a method obeys its contract. However, testing the configuration of an app or testing how a framework like Spring MVC calls or manipulates the data passed in. This is where integration testing comes in. Testing the app with everything wired in. End to end testing. This usually entails a tester firing up the browser and working through a list of test cases. This can be automated with something similar Test Director or made into JUnit test cases using HtmlUnit or HttpUnit. Creating a test case using HtmlUnit (or HttpUnit if you want to do more work) can be quiet tedious and time consuming. However there is a way to programmatically invoke the Spring's servlet and obtain the response object without having to parse html. By invoking it directly you gain a level of control, and the testing can be more specific. The downside is that you don't test the JSP files, though I'm sure there a

I had a massive headache trying to work out what data was passed to a procedure call that was using Spring's JdbcTemplate. The problem was, the parameters can be passed in as a map, so all you have is a set of names and value with no idea what order they go in. If you have a lot of statements to sift through then manually rebuilding the sql to execute is a pain. After trying many times to work out a way to extend CallableStatementCreatorFactory in order to pull out the information to build an sql statement I eventually reverted to just replacing the whole source file. Below is the resulting file, with date formatting (and select from dual) directed towards Oracle. Still useful for other vendors as it's pretty simple to adjust. I have no idea why this or something like it wasn't included in spring. /* * Copyright 2002-2006 the original author or authors. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except i

Hibernate has a Criteria API which allows you to dynamic build up filter conditions and set various join options. It is perfectly suited for flexible searches on entities, however there are areas in falls down in and the documentation is scarce. Criteria instances can be either created from the hibernate Session or a DetachedCriteria can be created for later execution or for passing into Spring's HibernateTemplate . The first thing that is explicitly mentioned is that references to properties can only be one deep, properties on child entities must be mapped via createAlias / createCriteria call. For example, the following will give a " org.hibernate.QueryException: could not resolve property: child.property of: com.example.model.Parent ". DetachedCriteria criteria = DetachedCriteria.forClass(Parent.class,"parent"); criteria.add(Restrictions.eq("parent.child.property", "somevalue"); Instead the child entity must be explicitly join by calling

I have come across two problems which have caused me no end of grief which turned out to be pretty simple. LazyInitializationException When using the Spring OpenSessionInViewFilter , I refer to lazily initialised properties (mapped as many-to-one or one-to-one ) in the JSP pages. However I was getting a scenario where if a user performed a certain action I would get the following error: org.hibernate.LazyInitializationException: could not initialize proxy - no Session After a lot of debugging and sifting through hibernate's source I traced it to a bit of code I had used that someone had posted for having a paged interval collection for hibernate (as oracle doesn't support server side paging). The culprit line of code was: hibernateTemplate .clear(); //which is defined in Spring's wrapper as public void clear() throws DataAccessException { executeWithNativeSession (new HibernateCallback () { public Object doInHibernate (Session session) { session.clear();

Spring Framework provides an easy way to unit test components in isolation and EasyMock provides a quick way to create mock objects with very little effort. Combining them together, Spring can be used to create the mock objects so that beans that use auto wiring to inject dependencies can be tested without having to modify the classes or create complex context configuration files. Creating mock objects using spring is simple, here is a sample beans.xml : <bean class="org.easymock.EasyMock" factory-method="createNiceMock" primary="true" id="someServiceMock"> <constructor-arg value="com.example.service.SomeService" /> </bean> This creates a mock object from the given interface. The primary is used to indicate that it should be used for autowiring which is useful when component scanning is used together with @Component tags. When you want to refer to the actual implementation you would use @Qualifier("someSe