Hi ceki,<br><br>thank you very much for your remarks :-)<br><br>Remark 1): yes i agree with you, that integration tests are also very usefull and only<br>with integration tests you know, that the software do what you want.<br>
<span id="result_box" class="" lang="en"><span class="hps">I</span> <span class="hps">thought</span> <span class="hps">that maybe</span> <span class="hps">Maven</span> <span class="hps">profiles could</span> <span class="hps">be very</span> <span class="hps">useful</span></span> to separate execution of<br>
integration tests. Only with profile (say "integration-tests") the integration tests will<br>be executed. Have we any Hudson/Jenkins instance for logback-extensions?<br><br>Remark 2): I am using TestNG only because it was included, not because I think it<br>
is necesary. I will change the logback-ext-mongodb unit tests to JUnit tests.<br><br>Remark 3):<br>>If I understand correctly, Jmockit relies on a java-agent to execute?<br>Yes, with jdk1.5 it relies on java-agent, with jdk1.6. it runs also without java-agent.<br>
We have jdk1.6. so we do not need any java-agent configurations, the tests run OTB.<br><br>Remark 4): Ohh ok, I will separate logback-ext-mongodb into classic and access ...<br>>Notwithstanding the above remarks, I am looking forward to testing<br>
logback-mongodb-* once I install MongoDB on my local machine.<br>OK please look also to <a href="https://github.com/qos-ch/logback-extensions/wiki/MongoDB">https://github.com/qos-ch/logback-extensions/wiki/MongoDB</a><br>
it contains a little tutorial for logback-access with Tomcat and MongoDB.<br><br>Regards<br>Christian<br><br><br><div class="gmail_quote">2012/6/18 ceki <span dir="ltr"><<a href="mailto:ceki@qos.ch" target="_blank">ceki@qos.ch</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Christian,<br>
<br>
I've mostly looked at the tests (not MongoDBAppender<br>
itself). Here are some preliminary remarks:<br>
<br>
1) Mocks in tests are very useful for certain tests. However, I don't<br>
think mock tests let us verify that MongoDBAppender actually works<br>
with MongoDB.<br>
<br>
We faced a similar problem with DBAppender which supports several<br>
databases such as oracle, mysqldb, postgresql, h2, etc. During the<br>
build, there are tests which actually run against these databases but<br>
only on "conforming" hosts, i.e. hosts that are known to run a<br>
database of certain type. Here is an except from<br>
DBAppenderIntegrationTest [1] which you might find useful.<br>
<br>
public class DBAppenderIntegrationTest {<br>
<br>
static String LOCAL_HOST_NAME; // set in setUpBeforeClass()<br>
static String[] MYSQL_CONFORMING_HOST_LIST = new String[] { "xharo" };<br>
<br>
@Test<br>
public void mysql() throws Exception {<br>
if (!<u></u>isConformingHostAndJDK16OrHigh<u></u>er(MYSQL_CONFORMING_HOST_LIST)<u></u>) {<br>
return;<br>
}<br>
doTest("src/test/input/<u></u>integration/db/mysql-with-<u></u>driver.xml");<br>
}<br>
<br>
static boolean isConformingHostAndJDK16OrHigh<u></u>er(<br>
String[] conformingHostList) {<br>
if (!Env.isJDK6OrHigher()) {<br>
return false;<br>
}<br>
for (String conformingHost : conformingHostList) {<br>
if (conformingHost.<u></u>equalsIgnoreCase(LOCAL_HOST_<u></u>NAME)) {<br>
return true;<br>
}<br>
}<br>
return false;<br>
}<br>
<br>
}<br>
<br>
The idea could perhaps be applied to MongoDB as well. We'd run<br>
integration tests on machines known to deploy MongoDB and skip the<br>
tests on most other machines.<br>
<br>
Remark 2)<br>
<br>
MongoDBAppender tests use TestNG. While TestNG offers some<br>
functionality beyond Junit, in my past experience, I often had to<br>
revert to Junit because it is better supported than TestNG by various<br>
tools, in particular IDEs. From what I could see, you care not using<br>
any TestNG specific features, so moving to Junit should be easy. If<br>
you really prefer TestNG, you are welcome to put the issue to a vote<br>
and we'll all use the tool with the most votes. However, it seems<br>
awkward to use TestNG in some parts of the project and JUnit in<br>
others. Relying on a must-have TestNG-only feature is a different<br>
matter which may justify TestNG in a particular test case.<br>
<br>
Remark 3)<br>
<br>
If I understand correctly, Jmockit relies on a java-agent to execute?<br>
Is there a way to run Jmockit without a javaagent?<br>
<br>
Remark 4)<br>
<br>
No logback-ext module should depend on logback-access and<br>
logback-classic at the same time. Otherwise, when such a module is<br>
used, it will pull in both logback-access and logback-classic into the<br>
client's project. This may have unintended consequences. In the most<br>
common deployment scenario, logback-access is deployed on the server's<br>
lib/ folder whereas logback-classic is deployed in a web-app. We don't<br>
want to break that common deployment scenario.<br>
<br>
Given the above, I would suggest to break mongodb into two modules,<br>
one for logback-access and one for logback-classic.<br>
<br>
Notwithstanding the above remarks, I am looking forward to testing<br>
logback-mongodb-* once I install MongoDB on my local machine.<br>
<br>
[1] <a href="http://tinyurl.com/d2anyzb" target="_blank">http://tinyurl.com/d2anyzb</a><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Ceki<br>
<a href="http://twitter.com/#%21/ceki" target="_blank">http://twitter.com/#!/ceki</a><br>
______________________________<u></u>_________________<br>
logback-dev mailing list<br>
<a href="mailto:logback-dev@qos.ch" target="_blank">logback-dev@qos.ch</a><br>
<a href="http://mailman.qos.ch/mailman/listinfo/logback-dev" target="_blank">http://mailman.qos.ch/mailman/<u></u>listinfo/logback-dev</a><br>
</font></span></blockquote></div><br>