Hi Christian, I've mostly looked at the tests (not MongoDBAppender itself). Here are some preliminary remarks: 1) Mocks in tests are very useful for certain tests. However, I don't think mock tests let us verify that MongoDBAppender actually works with MongoDB. We faced a similar problem with DBAppender which supports several databases such as oracle, mysqldb, postgresql, h2, etc. During the build, there are tests which actually run against these databases but only on "conforming" hosts, i.e. hosts that are known to run a database of certain type. Here is an except from DBAppenderIntegrationTest [1] which you might find useful. public class DBAppenderIntegrationTest { static String LOCAL_HOST_NAME; // set in setUpBeforeClass() static String[] MYSQL_CONFORMING_HOST_LIST = new String[] { "xharo" }; @Test public void mysql() throws Exception { if (!isConformingHostAndJDK16OrHigher(MYSQL_CONFORMING_HOST_LIST)) { return; } doTest("src/test/input/integration/db/mysql-with-driver.xml"); } static boolean isConformingHostAndJDK16OrHigher( String[] conformingHostList) { if (!Env.isJDK6OrHigher()) { return false; } for (String conformingHost : conformingHostList) { if (conformingHost.equalsIgnoreCase(LOCAL_HOST_NAME)) { return true; } } return false; } } The idea could perhaps be applied to MongoDB as well. We'd run integration tests on machines known to deploy MongoDB and skip the tests on most other machines. Remark 2) MongoDBAppender tests use TestNG. While TestNG offers some functionality beyond Junit, in my past experience, I often had to revert to Junit because it is better supported than TestNG by various tools, in particular IDEs. From what I could see, you care not using any TestNG specific features, so moving to Junit should be easy. If you really prefer TestNG, you are welcome to put the issue to a vote and we'll all use the tool with the most votes. However, it seems awkward to use TestNG in some parts of the project and JUnit in others. Relying on a must-have TestNG-only feature is a different matter which may justify TestNG in a particular test case. Remark 3) If I understand correctly, Jmockit relies on a java-agent to execute? Is there a way to run Jmockit without a javaagent? Remark 4) No logback-ext module should depend on logback-access and logback-classic at the same time. Otherwise, when such a module is used, it will pull in both logback-access and logback-classic into the client's project. This may have unintended consequences. In the most common deployment scenario, logback-access is deployed on the server's lib/ folder whereas logback-classic is deployed in a web-app. We don't want to break that common deployment scenario. Given the above, I would suggest to break mongodb into two modules, one for logback-access and one for logback-classic. Notwithstanding the above remarks, I am looking forward to testing logback-mongodb-* once I install MongoDB on my local machine. [1] http://tinyurl.com/d2anyzb -- Ceki http://twitter.com/#!/ceki