2012/6/18 ceki <ceki@qos.ch>

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
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-dev