You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by no...@apache.org on 2006/11/10 10:37:09 UTC
svn commit: r473287 -
/james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Author: norman
Date: Fri Nov 10 01:37:09 2006
New Revision: 473287
URL: http://svn.apache.org/viewvc?view=rev&rev=473287
Log:
Comment a broken test
Modified:
james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Modified: james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
URL: http://svn.apache.org/viewvc/james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java?view=diff&rev=473287&r1=473286&r2=473287
==============================================================================
--- james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java (original)
+++ james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java Fri Nov 10 01:37:09 2006
@@ -1017,7 +1017,10 @@
assertEquals("expected 250 ok", 250, smtpProtocol.getReplyCode());
}
-
+/**
+ * Noel please fix me!
+ *
+
public void testConnectionLimitExceeded() throws Exception {
m_testConfiguration.setConnectionLimit(1); // allow no more than one connection at a time
finishSetUp(m_testConfiguration);
@@ -1043,7 +1046,7 @@
smtpProtocol2.connect("127.0.0.1", m_smtpListenerPort);
assertTrue(smtpProtocol2.isConnected());
}
-
+*/
// RemoteDelivery tests.
InMemorySpoolRepository outgoingSpool;
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r473287 - /james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Posted by Stefano Bagnara <ap...@bago.org>.
The specific case is that probably the test is wrong.
Noel fixed the code but not the test, so the test now fails.
Commenting it out is not a good solution, I agree, because it decrease
coverage, but if really the test was wrong the problem is no more the
application to be fixed, but that we have to write a new unit test to
cover the new code, or to fix the old unit-test.
That said, I bet that Noel is simply busy now and that he will fix it as
soon as possible.
Stefano
Bernd Fondermann wrote:
> On 11/10/06, Stefano Bagnara <ap...@bago.org> wrote:
>> Bernd Fondermann wrote:
>> > -1. reason: from my experience, commenting out unit tests leads to a
>> > degeneration of the test base as a whole, on the long run making the
>> > unit tests more or less useless. a small improvement or fix does not
>> > justify leaving our tests compromised.
>>
>> Norman opened a JIRA issue assigned to Noel for this.
>> I think it is a good alternative to the other you're proposing.
>
> ok then, lets see if this helps. with the JIRA I am now -0 on the change.
>
> It is better to have unit tests run together with the main build anyway.
> It is more convenient to notice a problem before a commit and make the
> main code change and the unit test change together in one unit of
> work.
>
>> > o let us simply have the breaking test until it gets fixed - bad,
>> > because some tests are not run anymore but maybe we need some more
>> > days until it gets fixed, which is fine.
>>
>> Having a broken test may hide other problems arising from newer commits.
>
> ... and heightens the pressure to fix the failing test. ;-)
>
>> CI and Nightly builds no more give us useful output if we have a broken
>> test.
>>
>> That said if you don't retire the veto or don't apply any of the other
>> solution I will try to follow the first solution (remove the patch that
>> broke the test). I don't like this solution but I prefer it over having
>> failing builds because of the failing test.
>
> Succeeding tests (because of missing/commented tests) suggest that
> everything is good while it isn't.
> If the build fails, we are confronted with the fact that there is a
> problem.
>
> Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r473287 - /james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Posted by Bernd Fondermann <be...@googlemail.com>.
On 11/10/06, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann wrote:
> > -1. reason: from my experience, commenting out unit tests leads to a
> > degeneration of the test base as a whole, on the long run making the
> > unit tests more or less useless. a small improvement or fix does not
> > justify leaving our tests compromised.
>
> Norman opened a JIRA issue assigned to Noel for this.
> I think it is a good alternative to the other you're proposing.
ok then, lets see if this helps. with the JIRA I am now -0 on the change.
It is better to have unit tests run together with the main build anyway.
It is more convenient to notice a problem before a commit and make the
main code change and the unit test change together in one unit of
work.
> > o let us simply have the breaking test until it gets fixed - bad,
> > because some tests are not run anymore but maybe we need some more
> > days until it gets fixed, which is fine.
>
> Having a broken test may hide other problems arising from newer commits.
... and heightens the pressure to fix the failing test. ;-)
> CI and Nightly builds no more give us useful output if we have a broken
> test.
>
> That said if you don't retire the veto or don't apply any of the other
> solution I will try to follow the first solution (remove the patch that
> broke the test). I don't like this solution but I prefer it over having
> failing builds because of the failing test.
Succeeding tests (because of missing/commented tests) suggest that
everything is good while it isn't.
If the build fails, we are confronted with the fact that there is a problem.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r473287 - /james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
> -1. reason: from my experience, commenting out unit tests leads to a
> degeneration of the test base as a whole, on the long run making the
> unit tests more or less useless. a small improvement or fix does not
> justify leaving our tests compromised.
Norman opened a JIRA issue assigned to Noel for this.
I think it is a good alternative to the other you're proposing.
> instead, we should do one if the following
> o back out the original commit causing the test to fail - bad, because
> this committer does not care for the unit test, so does not care for
> quality?
Noel say that trunk is not quality code, maybe he simply wants to
enforce this :-)
> o fix the test immediately, because it gets harder every day it is not done
This need more time.
> o let us simply have the breaking test until it gets fixed - bad,
> because some tests are not run anymore but maybe we need some more
> days until it gets fixed, which is fine.
Having a broken test may hide other problems arising from newer commits.
CI and Nightly builds no more give us useful output if we have a broken
test.
That said if you don't retire the veto or don't apply any of the other
solution I will try to follow the first solution (remove the patch that
broke the test). I don't like this solution but I prefer it over having
failing builds because of the failing test.
Stefano
> Bernd
>
> On 11/10/06, norman@apache.org <no...@apache.org> wrote:
>> Author: norman
>> Date: Fri Nov 10 01:37:09 2006
>> New Revision: 473287
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=473287
>> Log:
>> Comment a broken test
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r473287 - /james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Posted by Bernd Fondermann <be...@googlemail.com>.
-1. reason: from my experience, commenting out unit tests leads to a
degeneration of the test base as a whole, on the long run making the
unit tests more or less useless. a small improvement or fix does not
justify leaving our tests compromised.
instead, we should do one if the following
o back out the original commit causing the test to fail - bad, because
this committer does not care for the unit test, so does not care for
quality?
o fix the test immediately, because it gets harder every day it is not done
o let us simply have the breaking test until it gets fixed - bad,
because some tests are not run anymore but maybe we need some more
days until it gets fixed, which is fine.
Bernd
On 11/10/06, norman@apache.org <no...@apache.org> wrote:
> Author: norman
> Date: Fri Nov 10 01:37:09 2006
> New Revision: 473287
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=473287
> Log:
> Comment a broken test
>
> Modified:
> james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
>
> Modified: james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
> URL: http://svn.apache.org/viewvc/james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java?view=diff&rev=473287&r1=473286&r2=473287
> ==============================================================================
> --- james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java (original)
> +++ james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java Fri Nov 10 01:37:09 2006
> @@ -1017,7 +1017,10 @@
> assertEquals("expected 250 ok", 250, smtpProtocol.getReplyCode());
>
> }
> -
> +/**
> + * Noel please fix me!
> + *
> +
> public void testConnectionLimitExceeded() throws Exception {
> m_testConfiguration.setConnectionLimit(1); // allow no more than one connection at a time
> finishSetUp(m_testConfiguration);
> @@ -1043,7 +1046,7 @@
> smtpProtocol2.connect("127.0.0.1", m_smtpListenerPort);
> assertTrue(smtpProtocol2.isConnected());
> }
> -
> +*/
> // RemoteDelivery tests.
>
> InMemorySpoolRepository outgoingSpool;
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org