-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Malcolm,
On 4/8/2010 9:08 AM, Malcolm Warren wrote: > I've been going round in circles for about two weeks now trying to work > out how to use Junit with Tomcat effectively. Are you trying to test your webapp via it's /web/ interface, or are you trying to test individual components via pure Java calls? > 1) I get my datasources from Tomcat, so I can't get to them from Junit You probably get your DataSources from JNDI, not Tomcat (though Tomcat does populate the JNDI context for you). There's a tool that I can't seem to find right now that basically provides a simple JNDI context that you can stuff full of data in your setUp method. In lieu of that, try reading some of these pages: http://www.coderanch.com/t/96030/Testing/Unit-testing-testing-JNDI-lookups http://ericholsinger.com/programming/java/junit-testing-jndi-datasources-thinking-outside-of-the-container/ Maybe most useful: http://commons.apache.org/dbcp/guide/jndi-howto.html > 2) I get the path in the file system to my Tomcat folder from Tomcat, > which is very convenient, but in consequence every path to a file in my > code depends on this. Do you mean that you use ServletContext.getRealPath or something similar? > For example I'm trying to test a method which uses a value from a > property file, but I can't do it, because the Junit test can't find the > property file path. How do you get the file path? > Searching the web again and again has brought up very little except Cactus. > Cactus on paper looks like a good idea, but Cactus has a very low > profile in google searches, which possibly means it is not used much. There's also HttpUnit if you want to test using HTTP calls. > But more important is the fact that it doesn't appear to be supported > any more since it uses an old version of Junit without annotations, and > I'm already used to the new version. IIRC, JUnit is very backward-compatible with itself. > I could probably code round the problem: but the recoding - just so that > I can test things effectively - will be enormous. We got around the problem by putting our DataSource acquisition into a separate class, something like this: public interface ConnectionFactory { public Connection getConnection() throws AppException; } public class JNDIConnectionFactory { public Connection getConnection() { InitialContext ctx = new InitialContext(); .. return ds.getConnection(); } } public class BaseService { public static void setConnectionFactory(ConnectionFactory cf) { ... } public static ConnectionFactory getConnectionFactory() { ... } public Connection getConnection() { return getConnectionFactory().getConnection(); } } public class MyActualService extends BaseService { public List<Foo> getFoos() { Connection conn = getConnection(); .. return foos; } } This allows us to run tests like this: public void setUp() { Connection conn = DriverManager.getConnection(...); BaseService.setConnectionFactory(new SimpleConnectionFactory(conn)); } or, if we want to skip the database altogether (which is usually the case): public void setUp() { Connection conn = new FakeJDBCConnection(); BaseService.setConnectionFactory(new SimpleConnectionFactory(conn)); } By moving all our JNDI code into the JNDIConnectionFactory class, we avoid lots of JNDI code in other places, and also gain the flexibility of being able to swap-in code that gets JDBC Connection objects in other ways. Still, I /swear/ that there's a simple standalone JNDI provider out there somewhere... - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAku97PAACgkQ9CaO5/Lv0PCLygCfUTJobGog6Gc4y1iIXpp4Q0+j c2MAoI7BLNr6HmZTlmvuZAIh0+lcK60z =xpkm -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
