You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2007/01/25 00:11:08 UTC
Velocity-Tools ImportSupport unit tests
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
[ At the request of Nathan Bubna, I am posting this to
dev@velocity.apache.org instead of bothering him individually ;) ]
Today, I have integrated the ImageSupport tests that I wrote into the
unit tests that are (as we speak) being added into svn.
Please find attached below my test case. It is a single file that
belongs in src/test/org/apache/velocity/tools/test/whitebox.
It relies on two additional libraries:
1. jmock (available at http://jmock.org/)
2. TestURLConnection (my own library, not attached as the list
identifies my post as SPAM if I do that)
Both of these JAR files need to go into test/lib in order to run the tests.
A couple of notes:
1. My TestURLConnection library is looking for a good home. Any
suggestions? I'm only providing the binary library which is
probably a deal-breaker for velocity-tools -- I know -- but I
was wondering if you know anyone in either jakarta-commons or
an incubator project who might be interested in this. I'd be
happy to provide you with the entire thing including source,
docs, etc.
2. My test case does not run properly unless "fork" is set to true in
the whitebox junit invocation. I'm not entirely sure why this is.
Also, I have an inner class that <junit> wants to run like a test,
and so that fails unless you change the fileset to be executed from
".../whitebox/**/*" to ".../whitebox/**/*Tests.class". I'd be happy
to learn how to suppress testing on an inner class so that this
doesn't cause a problem.
3. The "test.generic" ant target runs all whitebox testing and not
just the generic tests (well, now that my test is included, it
does). My test is definitely not a blackbox test, so I set it up
under the white box tests. Perhaps you guys aren't ready for more
tests and the method just needs to evolve as more tests are added.
Just a thought.
Let me know what you think.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFt+eL9CaO5/Lv0PARAtcjAKCyLd1hpJ+h35HD/NcYvzxtYxsptgCeL4nN
gEu8P0VTyQ8tyYEw0aU2t9Q=
=Ofs5
-----END PGP SIGNATURE-----
Re: Velocity-Tools ImportSupport unit tests
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nathan,
Nathan Bubna wrote:
> If it is an independent project that will not be fully
> absorbed/integrated into an existing project, then it is much easier
> to get interest if people are free to try the code out (i.e. there is
> a release they can download) and can check out the source for it from
> some public repository.
>
> If it is just a small set of classes/patches, then posting the code as
> JIRA attachments may be sufficient for people to see it and try it
> out.
It's 7 classes (and associated project stuff such as ant build scripts,
test code and libraries, etc.), which is on the border between a tiny
project and some utility tool in a larger project. It's a 11k binary JAR
and a 240k source ZIP file which contains everything.
> If you're willing to take the time to set it up and release it as an
> independent project, then that is the path i would recommend.
>
> Well, then i think you ought to create a project for it on Google Code
> or Sourceforge and do a release soon. Then i think we can look at
> getting the release uploaded into a maven repository and using it as a
> dependency of VelocityTools tests.
I certainly am willing to do all of this. I /want/ people to see the
source, give me feedback, etc.
To that end, I have created a project on SourceForge. It still needs to
be approved by a human over there before it gets up. I'll post a
followup at that point.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFyKym9CaO5/Lv0PARAg9MAJwNfHg0IQJCc6+Vc6aKlD58cOWNSACgh0MU
Fxrp1bI6tXS48GXnbkoRQS4=
=NXRY
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Velocity-Tools ImportSupport unit tests
Posted by Nathan Bubna <nb...@gmail.com>.
On 1/24/07, Christopher Schultz <ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nathan,
>
> Thanks for the quick response.
>
> Nathan Bubna wrote:
> > Code contributions are best through JIRA anyway, as that allows you to
> > mark it explicitly as contributed for use under the Apache License.
>
> Well, I decided to start here because of the library dependencies. I'm
> happy to tun everything through JIRA once there's an agreement.
>
> > Yeah, we're open source, so installing a binary-only [of your] library probably
> > won't work.
>
> Certainly. In fact, I /want/ to give this thing away. I've just been
> unable to get much guidance for the best way to do it.
>
> > However, it's not really that difficult to start your
> > own open source project for this at Google Code
> > (http://code.google.com/hosting/createProject) or SourceForge
> > (http://sourceforge.net/register/). Once it is set up there, that
> > makes it much easier for people to try it out or check out the code,
> > which in turn makes it much, much easier to find a better home for it
> > or else build a dev community around it there.
>
> I was operating based upon a rumor that the ASF doesn't like to use libs
> and stuff that are either non-ASF or that operate under certain types of
> licenses. I wanted to make sure that whatever I did wasn't a deal-breaker.
The official doctrine is that ASF projects are encouraged (but
definitely not required) to use other ASF projects wherever possible.
However, ASF projects regularly and happily use non-ASF software
(assuming the license allows) for needs which cannot be served by
another ASF project. So, for instance, VelocityStruts happily makes
use of the SSL-Ext project, which is hosted by sourceforge.
Certain types of licenses can definitely be problematic. I'm no
expert in this field, but if you are interested in a non-Apache
license, then let me know which one and i'll help you find out if and
how we can use it as an Apache project.
> > In fact, depending on what license you put it under (i recommend ASL
> > 2.0 :), once you set it up and release a version, we would then be
> > able to integrate it into the VelocityTools tests and increase it's
> > exposure for you.
>
> I was kinda hoping that Jakarta Commons would express interest, but it's
> kind of unclear how to donate something like this.
Donating needn't be that difficult. You could just find a project
which looks like it could use your code, create a new JIRA issue,
attach your code, and mark it as a contribution under the ASL. But of
course, that's no guarantee anything will be done with it.
It's getting an existing ASF project to *adopt* code that is tricky.
The PMC (Project Management Committee) for the adopting project has to
want the code first. Even once they do, some large code donations
must be brought through the incubator, though i'm not fully versed in
all the situations where that is or isn't required. The most
important thing is getting a PMC to want the code. Once you have the
interest, the rest is usually just procedure, and members of that PMC
should help you through it.
If it is an independent project that will not be fully
absorbed/integrated into an existing project, then it is much easier
to get interest if people are free to try the code out (i.e. there is
a release they can download) and can check out the source for it from
some public repository.
If it is just a small set of classes/patches, then posting the code as
JIRA attachments may be sufficient for people to see it and try it
out.
> > If you're willing to take the time to set it up and release it as an
> > independent project, then that is the path i would recommend.
>
> It's all set up and ready to go, actually. Just looking for a good home
> and for me to choose a license (ASF is just fine with me).
Well, then i think you ought to create a project for it on Google Code
or Sourceforge and do a release soon. Then i think we can look at
getting the release uploaded into a maven repository and using it as a
dependency of VelocityTools tests.
> Thanks again,
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFt/dZ9CaO5/Lv0PARAhTCAJ9OHzOlAhro1gaQD+gpfZ1sEelOrQCdEBhb
> ddOsdqLN5/3IODZwdQAibiA=
> =bvqN
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Velocity-Tools ImportSupport unit tests
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nathan,
Thanks for the quick response.
Nathan Bubna wrote:
> Code contributions are best through JIRA anyway, as that allows you to
> mark it explicitly as contributed for use under the Apache License.
Well, I decided to start here because of the library dependencies. I'm
happy to tun everything through JIRA once there's an agreement.
> Yeah, we're open source, so installing a binary-only [of your] library probably
> won't work.
Certainly. In fact, I /want/ to give this thing away. I've just been
unable to get much guidance for the best way to do it.
> However, it's not really that difficult to start your
> own open source project for this at Google Code
> (http://code.google.com/hosting/createProject) or SourceForge
> (http://sourceforge.net/register/). Once it is set up there, that
> makes it much easier for people to try it out or check out the code,
> which in turn makes it much, much easier to find a better home for it
> or else build a dev community around it there.
I was operating based upon a rumor that the ASF doesn't like to use libs
and stuff that are either non-ASF or that operate under certain types of
licenses. I wanted to make sure that whatever I did wasn't a deal-breaker.
> In fact, depending on what license you put it under (i recommend ASL
> 2.0 :), once you set it up and release a version, we would then be
> able to integrate it into the VelocityTools tests and increase it's
> exposure for you.
I was kinda hoping that Jakarta Commons would express interest, but it's
kind of unclear how to donate something like this.
> If you're willing to take the time to set it up and release it as an
> independent project, then that is the path i would recommend.
It's all set up and ready to go, actually. Just looking for a good home
and for me to choose a license (ASF is just fine with me).
Thanks again,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFt/dZ9CaO5/Lv0PARAhTCAJ9OHzOlAhro1gaQD+gpfZ1sEelOrQCdEBhb
ddOsdqLN5/3IODZwdQAibiA=
=bvqN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Velocity-Tools ImportSupport unit tests
Posted by Nathan Bubna <nb...@gmail.com>.
Thanks! Archives and more eyes are very good things. :)
Responses inline:
On 1/24/07, Christopher Schultz <ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All,
>
> [ At the request of Nathan Bubna, I am posting this to
> dev@velocity.apache.org instead of bothering him individually ;) ]
>
> Today, I have integrated the ImageSupport tests that I wrote into the
> unit tests that are (as we speak) being added into svn.
>
> Please find attached below my test case. It is a single file that
> belongs in src/test/org/apache/velocity/tools/test/whitebox.
>
> It relies on two additional libraries:
>
> 1. jmock (available at http://jmock.org/)
> 2. TestURLConnection (my own library, not attached as the list
> identifies my post as SPAM if I do that)
Code contributions are best through JIRA anyway, as that allows you to
mark it explicitly as contributed for use under the Apache License.
> Both of these JAR files need to go into test/lib in order to run the tests.
>
> A couple of notes:
>
> 1. My TestURLConnection library is looking for a good home. Any
> suggestions? I'm only providing the binary library which is
> probably a deal-breaker for velocity-tools -- I know -- but I
> was wondering if you know anyone in either jakarta-commons or
> an incubator project who might be interested in this. I'd be
> happy to provide you with the entire thing including source,
> docs, etc.
Yeah, we're open source, so installing a binary-only library probably
won't work. However, it's not really that difficult to start your
own open source project for this at Google Code
(http://code.google.com/hosting/createProject) or SourceForge
(http://sourceforge.net/register/). Once it is set up there, that
makes it much easier for people to try it out or check out the code,
which in turn makes it much, much easier to find a better home for it
or else build a dev community around it there.
In fact, depending on what license you put it under (i recommend ASL
2.0 :), once you set it up and release a version, we would then be
able to integrate it into the VelocityTools tests and increase it's
exposure for you.
The only other possibility for us being able to use TestURLConnection
in VelocityTools is if we decided to adopt the code ourselves and make
it part of our own little test framework. Consideration of this would
probably have to wait until VelocityTools 1.3 is released and i am
definitely open to it if it means thorough testing of ImportSupport,
however, it probably would not give as much exposure or freedom to
your library.
If you're willing to take the time to set it up and release it as an
independent project, then that is the path i would recommend.
> 2. My test case does not run properly unless "fork" is set to true in
> the whitebox junit invocation. I'm not entirely sure why this is.
> Also, I have an inner class that <junit> wants to run like a test,
> and so that fails unless you change the fileset to be executed from
> ".../whitebox/**/*" to ".../whitebox/**/*Tests.class". I'd be happy
> to learn how to suppress testing on an inner class so that this
> doesn't cause a problem.
i'm not sure. Claude might have a better idea. I'm still a noob when
it comes to junit.
> 3. The "test.generic" ant target runs all whitebox testing and not
> just the generic tests (well, now that my test is included, it
> does). My test is definitely not a blackbox test, so I set it up
> under the white box tests. Perhaps you guys aren't ready for more
> tests and the method just needs to evolve as more tests are added.
> Just a thought.
We would probably either have to change "test.generic" to
"test.whitebox" or else add a new "greybox" or something. Claude, are
you reading this? I'd love to hear your thoughts on where
non-blackbox testing of VelocityView (not Generic) tools should go.
> Let me know what you think.
>
> - -chris
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFt+eL9CaO5/Lv0PARAtcjAKCyLd1hpJ+h35HD/NcYvzxtYxsptgCeL4nN
> gEu8P0VTyQ8tyYEw0aU2t9Q=
> =Ofs5
> -----END PGP SIGNATURE-----
>
>
> package org.apache.velocity.tools.test.whitebox;
>
> import java.util.Map;
> import java.io.IOException;
> import java.io.InputStreamReader;
> import java.io.Reader;
>
> import org.junit.Test;
> import org.junit.BeforeClass;
> import junit.framework.Assert;
> import junit.framework.TestCase;
>
> import org.jmock.Mock;
> import org.jmock.MockObjectTestCase;
>
> import org.apache.velocity.tools.view.ImportSupport;
> import org.apache.velocity.tools.test.loopback.Handler;
>
> import net.christopherschultz.testurl.HttpURLConnection;
> import net.christopherschultz.testurl.URLConnectionRegistry;
>
> public class ImportSupportTests
> extends MockObjectTestCase
> {
> // Need a concrete class; must be public else junit complains
> public static class ImportSupportImpl
> extends ImportSupport
> {
> public String acquireString(String url)
> throws IOException, Exception
> {
> return super.acquireString(url);
> }
> public Reader acquireReader(String url)
> throws IOException, Exception
> {
> return super.acquireReader(url);
> }
> }
>
> private ImportSupportImpl is = new ImportSupportImpl();
> public @BeforeClass void setUp()
> {
> URLConnectionRegistry.clear();
> URLConnectionRegistry.registerURLStreamHandler();
> }
>
> public @Test void testAcquireString()
> throws Exception
> {
> String response = "<html><h1>Test\u1234Content</h1></html>";
> java.io.ByteArrayInputStream data
> = new java.io.ByteArrayInputStream(response.getBytes("UTF-8"));
>
> Mock m_conn = new Mock(HttpURLConnection.class);
>
> m_conn.expects(once()).method("getInputStream").will(returnValue(data));
> m_conn.expects(once()).method("getResponseCode").will(returnValue(200));
> m_conn.expects(once()).method("getContentType").will(returnValue("text/html; charset=UTF-8"));
> m_conn.expects(once()).method("disconnect");
>
> URLConnectionRegistry.register("test/url",
> (HttpURLConnection)m_conn.proxy());
>
> // Make the request
> String content = is.acquireString("testurl:test/url");
>
> Assert.assertEquals(response, content);
>
> m_conn.verify();
> }
>
> public @Test void testAcquireReader()
> throws Exception
> {
> String response = "<html><h1>Test\u1234Content</h1></html>";
> java.io.ByteArrayInputStream data
> = new java.io.ByteArrayInputStream(response.getBytes("UTF-8"));
>
> Mock m_conn = new Mock(HttpURLConnection.class);
>
> m_conn.expects(once()).method("getInputStream").will(returnValue(data));
> m_conn.expects(once()).method("getResponseCode").will(returnValue(200));
> m_conn.expects(once()).method("getContentType").will(returnValue("text/html; charset=UTF-8"));
> m_conn.expects(once()).method("disconnect");
>
> URLConnectionRegistry.register("test/url",
> (HttpURLConnection)m_conn.proxy());
>
> // Make the request
> Reader r = is.acquireReader("testurl:test/url");
>
> // Make sure that the response used the correct charset
> char[] chars = new char[1024];
> int count = r.read(chars);
>
> String content = new String(chars, 0, count);
>
> r.close(); // should trigger a disconnect.
>
> Assert.assertEquals("Character encoding appears to be lost.",
> response,
> content);
>
> m_conn.verify();
> }
>
> public ImportSupportTests(String name)
> {
> super(name);
> }
> }
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org