Hi ceki, thank you very much for your remarks :-)
Remark 1): yes i agree with you, that integration tests are also very usefull and only with integration tests you know, that the software do what you want. I thought that maybe Maven profiles could be very useful to separate execution of integration tests. Only with profile (say "integration-tests") the integration tests will be executed. Have we any Hudson/Jenkins instance for logback-extensions? Remark 2): I am using TestNG only because it was included, not because I think it is necesary. I will change the logback-ext-mongodb unit tests to JUnit tests. Remark 3): >If I understand correctly, Jmockit relies on a java-agent to execute? Yes, with jdk1.5 it relies on java-agent, with jdk1.6. it runs also without java-agent. We have jdk1.6. so we do not need any java-agent configurations, the tests run OTB. Remark 4): Ohh ok, I will separate logback-ext-mongodb into classic and access ... >Notwithstanding the above remarks, I am looking forward to testing logback-mongodb-* once I install MongoDB on my local machine. OK please look also to https://github.com/qos-ch/logback-extensions/wiki/MongoDB it contains a little tutorial for logback-access with Tomcat and MongoDB. Regards Christian 2012/6/18 ceki <[email protected]> > 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 (!**isConformingHostAndJDK16OrHigh**er(MYSQL_CONFORMING_HOST_LIST)**) > { > return; > } > doTest("src/test/input/**integration/db/mysql-with-**driver.xml"); > } > > static boolean isConformingHostAndJDK16OrHigh**er( > 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 > [email protected] > http://mailman.qos.ch/mailman/**listinfo/logback-dev<http://mailman.qos.ch/mailman/listinfo/logback-dev> >
_______________________________________________ logback-dev mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/logback-dev
