Looking at MongoDBAppender
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
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 <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 (!**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 logback-dev@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-dev<http://mailman.qos.ch/mailman/listinfo/logback-dev>
On 18.06.2012 17:32, Christian Trutz wrote:
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?
You would need to have an oracle-profile, mysql-profile, postgres-profile and mongo-db profile. I think it might be easier to keep track of the machines in code as is done in DBAppenderIntegrationTest. Using profiles has the advantage of decoupling the tests run from the test code. The isConformantHost check is quick-and-dirty but gets the job done. There is no Jenkins instance for logback/logback-extensions. There was a CI for logback a few years back but I no longer had the time to maintain the instance.
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.
That would be great thanks.
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.
Looking at [1], although ootb there is a javaagent attached to the JVM. I might be wrong here but using a Java agent to run tests seems like an awfully heavy handed method. It affects every single class loaded into memory. The MockitoJUnitRunner approach seems less invasive imho. [1] http://tinyurl.com/cflvr9r
Remark 4): Ohh ok, I will separate logback-ext-mongodb into classic and access ...
Thank you. To be precise, it's actually logback-mongodb-parent pom module plus 3 children: logback-mongodb-core, logback-mongodb-classic and logback-mongodb-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
I think it would be easier if you could push the docs onto http://logback.qos.ch directly. We can discuss this later. -- Ceki http://twitter.com/#!/ceki
Hi Ceki,
There is no Jenkins instance for logback/logback-extensions. There was a CI for logback a few years back but I no longer had the time to maintain the instance.
I configure a Jenkins instance on http://www.cloudbees.com/ for logback-extensions 1) a new build is triggered instantly after a "git push" on GitHub (via service hook) 2) Jenkins instance is https://smilebase.ci.cloudbees.com/ 3) if build fails a email is send to logback-dev@qos.ch Christian 2012/6/18 ceki <ceki@qos.ch>
On 18.06.2012 17:32, Christian Trutz wrote:
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?
You would need to have an oracle-profile, mysql-profile, postgres-profile and mongo-db profile. I think it might be easier to keep track of the machines in code as is done in DBAppenderIntegrationTest. Using profiles has the advantage of decoupling the tests run from the test code. The isConformantHost check is quick-and-dirty but gets the job done.
There is no Jenkins instance for logback/logback-extensions. There was a CI for logback a few years back but I no longer had the time to maintain the instance.
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.
That would be great thanks.
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.
Looking at [1], although ootb there is a javaagent attached to the JVM. I might be wrong here but using a Java agent to run tests seems like an awfully heavy handed method. It affects every single class loaded into memory. The MockitoJUnitRunner approach seems less invasive imho.
[1] http://tinyurl.com/cflvr9r
Remark 4): Ohh ok, I will separate logback-ext-mongodb into classic and
access ...
Thank you. To be precise, it's actually logback-mongodb-parent pom module plus 3 children: logback-mongodb-core, logback-mongodb-classic and logback-mongodb-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<https://github.com/qos-ch/logback-extensions/wiki/MongoDB>
I think it would be easier if you could push the docs onto http://logback.qos.ch directly. We can discuss this later.
-- Ceki http://twitter.com/#!/ceki ______________________________**_________________ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-dev<http://mailman.qos.ch/mailman/listinfo/logback-dev>
Hi all, updated 2): Jenkins instance is NOT https://smilebase.ci.cloudbees.com/ ! The correct URL is https://logback.ci.cloudbees.com @ceki: you are now admin of https://logback.ci.cloudbees.com If someone wants to access the Jenkins instance, please create an Cloudbees account and send me an email. @ceki: can you please add the email address jenkins-no-reply@cloudbees.com to logback-dev@qos.ch mailing list? So that Jenkins notifications will also be posted to logback-dev@qos.ch ... Christian 2012/6/18 Christian Trutz <christian.trutz@belaso.de>
Hi Ceki,
There is no Jenkins instance for logback/logback-extensions. There was a CI for logback a few years back but I no longer had the time to maintain the instance.
I configure a Jenkins instance on http://www.cloudbees.com/ for logback-extensions
1) a new build is triggered instantly after a "git push" on GitHub (via service hook) 2) Jenkins instance is https://smilebase.ci.cloudbees.com/ 3) if build fails a email is send to logback-dev@qos.ch
Christian
2012/6/18 ceki <ceki@qos.ch>
On 18.06.2012 17:32, Christian Trutz wrote:
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?
You would need to have an oracle-profile, mysql-profile, postgres-profile and mongo-db profile. I think it might be easier to keep track of the machines in code as is done in DBAppenderIntegrationTest. Using profiles has the advantage of decoupling the tests run from the test code. The isConformantHost check is quick-and-dirty but gets the job done.
There is no Jenkins instance for logback/logback-extensions. There was a CI for logback a few years back but I no longer had the time to maintain the instance.
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.
That would be great thanks.
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.
Looking at [1], although ootb there is a javaagent attached to the JVM. I might be wrong here but using a Java agent to run tests seems like an awfully heavy handed method. It affects every single class loaded into memory. The MockitoJUnitRunner approach seems less invasive imho.
[1] http://tinyurl.com/cflvr9r
Remark 4): Ohh ok, I will separate logback-ext-mongodb into classic and
access ...
Thank you. To be precise, it's actually logback-mongodb-parent pom module plus 3 children: logback-mongodb-core, logback-mongodb-classic and logback-mongodb-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<https://github.com/qos-ch/logback-extensions/wiki/MongoDB>
I think it would be easier if you could push the docs onto http://logback.qos.ch directly. We can discuss this later.
-- Ceki http://twitter.com/#!/ceki ______________________________**_________________ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-dev<http://mailman.qos.ch/mailman/listinfo/logback-dev>
participants (2)
-
ceki -
Christian Trutz