You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Nick Williams <ni...@nicholaswilliams.net> on 2013/08/20 15:13:09 UTC
Need guidance for writing unit tests for 55317
I'm working on implementing bugzilla 55317. It's a pretty important change (weaving) to a pretty import class (WebappClassLoader), so it obviously needs some unit tests. However, I need some guidance:
1) I've never gotten all the existing tests to pass on my machine. Last time I ran them it took 45 minutes (holy crap) and about 1/3 of them failed. This is obviously something wrong with my configuration and not with Tomcat. I'd like to avoid running all tests for this reason and only run the particular tests I'm working on. How would I do this? Is this even possible with Ant?
2) I'm not sure exactly how to approach testing this particular feature. It's obviously not completely straightforward. This is weaving we're talking about, so somehow I have to load a class and weave it to test that it's properly woven. Suggestions on where to get started / what tools to use? As much as I hate it, part of me is saying that functional testing is really the best course here, in which case this is all moot.
3) I'm not even sure how to approach testing in Tomcat in general. I've seen a lot of "unit tests" that look more like integration tests, at least according to my training. Are there general guidelines for writing "correct" unit tests in Tomcat, or is in generally accepted as long as it passes?
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Need guidance for writing unit tests for 55317
Posted by Brian Burch <br...@pingtoo.com>.
On 20/08/13 14:32, Violeta Georgieva wrote:
> 2013/8/20 Nick Williams wrote:
>>
>> I'm working on implementing bugzilla 55317. It's a pretty important
> change (weaving) to a pretty import class (WebappClassLoader), so it
> obviously needs some unit tests. However, I need some guidance:
>>
>> 1) I've never gotten all the existing tests to pass on my machine. Last
> time I ran them it took 45 minutes (holy crap) and about 1/3 of them
> failed. This is obviously something wrong with my configuration and not
> with Tomcat. I'd like to avoid running all tests for this reason and only
> run the particular tests I'm working on. How would I do this? Is this even
> possible with Ant?
>>
>
>
> It is explained in BUILDING.txt
> "(7.2) Running a single test
> It is possible to run a single JUnit test class by adding the "test.entry"
> property to the build.properties file. The property specifies the name of
> the test class.
>
> For example:
>
> test.entry=org.apache.catalina.util.TestServerInfo"
e.g. this works for me..
ant
-Dtest.name=org.apache.catalina.authenticator.TestNonLoginAndBasicAuthenticator
test
> Also I run them directly in IDE as JUnit tests.
+1 - works for the individual test classes under netbeans. Most people
seem to use eclipse, but I can't speak for them.
Regards,
Brian
>
> Regards
> Violeta
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Need guidance for writing unit tests for 55317
Posted by Violeta Georgieva <mi...@gmail.com>.
2013/8/20 Nick Williams wrote:
>
> I'm working on implementing bugzilla 55317. It's a pretty important
change (weaving) to a pretty import class (WebappClassLoader), so it
obviously needs some unit tests. However, I need some guidance:
>
> 1) I've never gotten all the existing tests to pass on my machine. Last
time I ran them it took 45 minutes (holy crap) and about 1/3 of them
failed. This is obviously something wrong with my configuration and not
with Tomcat. I'd like to avoid running all tests for this reason and only
run the particular tests I'm working on. How would I do this? Is this even
possible with Ant?
>
It is explained in BUILDING.txt
"(7.2) Running a single test
It is possible to run a single JUnit test class by adding the "test.entry"
property to the build.properties file. The property specifies the name of
the test class.
For example:
test.entry=org.apache.catalina.util.TestServerInfo"
Also I run them directly in IDE as JUnit tests.
Regards
Violeta
Re: Need guidance for writing unit tests for 55317
Posted by Mark Thomas <ma...@apache.org>.
On 20/08/2013 18:58, Christopher Schultz wrote:
> In case you want to run the entire test suite but don't want to get
> APR failures, you can also set -Dexecute.test.apr=false and it will
> skip all the APR tests.
The unit tests are smart enough that even with that set to true, the
tests will be skipped for APR if the library is not found.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Need guidance for writing unit tests for 55317
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Nick,
On 8/20/13 1:47 PM, Nick Williams wrote:
>
> On Aug 20, 2013, at 12:41 PM, Christopher Schultz wrote:
>
>> Nick,
>>
>> On 8/20/13 1:25 PM, Christopher Schultz wrote:
>>> tcnative can be built on Max OS X like this:
>>>
>>> $ cd $CATALINA_HOME/bin
>>> $ tar xzf tomcat-native.tar.gz
>>> $ cd tomcat-native-*-src/jni/native
>>> $ ./configure --with-apr=/usr/bin/apr-1-config --with-ssl
>>> --with-java-home=`/usr/libexec/java_home`
>>>
>>> At this point, configure chokes on my system because it's trying to find
>>> 'cc' under Xcode.app and I'm not sure where it's sniffing that directory
>>> base from. Maybe you'll have better luck. I'll reply if I figure it out.
>>
>> Okay, it seems that apr-1-config is giving the wrong path for 'cc' to
>> configure. I'm investigating…
>
> I don't have a particular need to build this, especial not on Mac OS X right now. I'm working in Windows 7.
>
> My remaining original concern was the best approach for weaving byte code in Tomcat's unit tests, which I detailed in an earlier message.
Good point. You don't need to run any tests that use any connectors at
all, really. So if you just use -Dtest.entry that should basically solve
all your problems :)
In case you want to run the entire test suite but don't want to get APR
failures, you can also set -Dexecute.test.apr=false and it will skip all
the APR tests.
-chris
Re: Need guidance for writing unit tests for 55317
Posted by Nick Williams <ni...@nicholaswilliams.net>.
On Aug 21, 2013, at 12:46 PM, sebb wrote:
> On 21 August 2013 14:48, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>> Nick,
>>
>> On 8/20/13 8:24 PM, Nick Williams wrote:
>>> I ran in to a roadblock with this idea. Part of the byte code of a
>>> class includes the fully-qualified class name. If I create a class,
>>> say UnweavedClass, and replace its byte code in my fake transformer
>>> with that of another class, the FQCN changes. This results in a
>>> NoClassDefFoundError because the class loader is looking for
>>> UnweavenClass in be in the byte code when really some other class
>>> is.
>>>
>>> My backup idea is slightly less clean but, IMO, still more clean than
>>> adding ASM as a test-time dependency and trying to figure all of that
>>> out. I locally compiled fake "weaved" versions of the UnweavedClass
>>> (with the modified behavior) and then translated each version into a
>>> Java byte array definition. (These are extremely simple on-line,
>>> one-method classes, so the byte arrays are relatively short.) I then
>>> simply embedded the byte array definitions as static final byte[]
>>> fields the test class and replaced the byte code in my fake
>>> transformer with those embedded fields' content. I've tested this and
>>> it works great.
>>
>> Any reason not to simply compile some .java source into a .class file
>> and read it from the disk instead of shoving it into a byte array?
>> There's nothing stopping you from doing an offline-compile of a .java
>> file into a .class file and committing both to svn. You don't have to
>> compile the .java source as part of the test -- just load it off disk as
>> part of the test.
>>
>> This will allow easier inspection of the .class file, and not be such a
>> pain in the neck to change the bytecode if necessary.
>
> Is there any mileage in using the features of JSR199?
That would require a bit more code than the current solution Mark and I agreed on. The approach I took was the simplest approach possible, IMO.
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Need guidance for writing unit tests for 55317
Posted by sebb <se...@gmail.com>.
On 21 August 2013 20:21, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> Sebb,
>
> On 8/21/13 1:46 PM, sebb wrote:
>> On 21 August 2013 14:48, Christopher Schultz
>> <ch...@christopherschultz.net> wrote:
>>> Nick,
>>>
>>> On 8/20/13 8:24 PM, Nick Williams wrote:
>>>> I ran in to a roadblock with this idea. Part of the byte code of a
>>>> class includes the fully-qualified class name. If I create a class,
>>>> say UnweavedClass, and replace its byte code in my fake transformer
>>>> with that of another class, the FQCN changes. This results in a
>>>> NoClassDefFoundError because the class loader is looking for
>>>> UnweavenClass in be in the byte code when really some other class
>>>> is.
>>>>
>>>> My backup idea is slightly less clean but, IMO, still more clean than
>>>> adding ASM as a test-time dependency and trying to figure all of that
>>>> out. I locally compiled fake "weaved" versions of the UnweavedClass
>>>> (with the modified behavior) and then translated each version into a
>>>> Java byte array definition. (These are extremely simple on-line,
>>>> one-method classes, so the byte arrays are relatively short.) I then
>>>> simply embedded the byte array definitions as static final byte[]
>>>> fields the test class and replaced the byte code in my fake
>>>> transformer with those embedded fields' content. I've tested this and
>>>> it works great.
>>>
>>> Any reason not to simply compile some .java source into a .class file
>>> and read it from the disk instead of shoving it into a byte array?
>>> There's nothing stopping you from doing an offline-compile of a .java
>>> file into a .class file and committing both to svn. You don't have to
>>> compile the .java source as part of the test -- just load it off disk as
>>> part of the test.
>>>
>>> This will allow easier inspection of the .class file, and not be such a
>>> pain in the neck to change the bytecode if necessary.
>>
>> Is there any mileage in using the features of JSR199?
>
> Is that widely-deployed? I don't believe its a part of, for instance,
> Java 7 SE.
I understood it to be part of Java 6 [1], but perhaps I misunderstood.
Alternatively, since Tomcat uses ECJ, it could perhaps use that to compile.
The Commons JCI component has an Eclipse compiler; however there is an
issue with it at present [2]
[1] https://blogs.oracle.com/jjg/entry/jsr_199_meets_jsr_203
[2] https://issues.apache.org/jira/browse/JCI-59
> -chris
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Need guidance for writing unit tests for 55317
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Sebb,
On 8/21/13 1:46 PM, sebb wrote:
> On 21 August 2013 14:48, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>> Nick,
>>
>> On 8/20/13 8:24 PM, Nick Williams wrote:
>>> I ran in to a roadblock with this idea. Part of the byte code of a
>>> class includes the fully-qualified class name. If I create a class,
>>> say UnweavedClass, and replace its byte code in my fake transformer
>>> with that of another class, the FQCN changes. This results in a
>>> NoClassDefFoundError because the class loader is looking for
>>> UnweavenClass in be in the byte code when really some other class
>>> is.
>>>
>>> My backup idea is slightly less clean but, IMO, still more clean than
>>> adding ASM as a test-time dependency and trying to figure all of that
>>> out. I locally compiled fake "weaved" versions of the UnweavedClass
>>> (with the modified behavior) and then translated each version into a
>>> Java byte array definition. (These are extremely simple on-line,
>>> one-method classes, so the byte arrays are relatively short.) I then
>>> simply embedded the byte array definitions as static final byte[]
>>> fields the test class and replaced the byte code in my fake
>>> transformer with those embedded fields' content. I've tested this and
>>> it works great.
>>
>> Any reason not to simply compile some .java source into a .class file
>> and read it from the disk instead of shoving it into a byte array?
>> There's nothing stopping you from doing an offline-compile of a .java
>> file into a .class file and committing both to svn. You don't have to
>> compile the .java source as part of the test -- just load it off disk as
>> part of the test.
>>
>> This will allow easier inspection of the .class file, and not be such a
>> pain in the neck to change the bytecode if necessary.
>
> Is there any mileage in using the features of JSR199?
Is that widely-deployed? I don't believe its a part of, for instance,
Java 7 SE.
-chris
Re: Need guidance for writing unit tests for 55317
Posted by sebb <se...@gmail.com>.
On 21 August 2013 14:48, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> Nick,
>
> On 8/20/13 8:24 PM, Nick Williams wrote:
>> I ran in to a roadblock with this idea. Part of the byte code of a
>> class includes the fully-qualified class name. If I create a class,
>> say UnweavedClass, and replace its byte code in my fake transformer
>> with that of another class, the FQCN changes. This results in a
>> NoClassDefFoundError because the class loader is looking for
>> UnweavenClass in be in the byte code when really some other class
>> is.
>>
>> My backup idea is slightly less clean but, IMO, still more clean than
>> adding ASM as a test-time dependency and trying to figure all of that
>> out. I locally compiled fake "weaved" versions of the UnweavedClass
>> (with the modified behavior) and then translated each version into a
>> Java byte array definition. (These are extremely simple on-line,
>> one-method classes, so the byte arrays are relatively short.) I then
>> simply embedded the byte array definitions as static final byte[]
>> fields the test class and replaced the byte code in my fake
>> transformer with those embedded fields' content. I've tested this and
>> it works great.
>
> Any reason not to simply compile some .java source into a .class file
> and read it from the disk instead of shoving it into a byte array?
> There's nothing stopping you from doing an offline-compile of a .java
> file into a .class file and committing both to svn. You don't have to
> compile the .java source as part of the test -- just load it off disk as
> part of the test.
>
> This will allow easier inspection of the .class file, and not be such a
> pain in the neck to change the bytecode if necessary.
Is there any mileage in using the features of JSR199?
> -chris
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Need guidance for writing unit tests for 55317
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Nick,
On 8/20/13 8:24 PM, Nick Williams wrote:
> I ran in to a roadblock with this idea. Part of the byte code of a
> class includes the fully-qualified class name. If I create a class,
> say UnweavedClass, and replace its byte code in my fake transformer
> with that of another class, the FQCN changes. This results in a
> NoClassDefFoundError because the class loader is looking for
> UnweavenClass in be in the byte code when really some other class
> is.
>
> My backup idea is slightly less clean but, IMO, still more clean than
> adding ASM as a test-time dependency and trying to figure all of that
> out. I locally compiled fake "weaved" versions of the UnweavedClass
> (with the modified behavior) and then translated each version into a
> Java byte array definition. (These are extremely simple on-line,
> one-method classes, so the byte arrays are relatively short.) I then
> simply embedded the byte array definitions as static final byte[]
> fields the test class and replaced the byte code in my fake
> transformer with those embedded fields' content. I've tested this and
> it works great.
Any reason not to simply compile some .java source into a .class file
and read it from the disk instead of shoving it into a byte array?
There's nothing stopping you from doing an offline-compile of a .java
file into a .class file and committing both to svn. You don't have to
compile the .java source as part of the test -- just load it off disk as
part of the test.
This will allow easier inspection of the .class file, and not be such a
pain in the neck to change the bytecode if necessary.
-chris
Re: Need guidance for writing unit tests for 55317
Posted by Nick Williams <ni...@nicholaswilliams.net>.
On Aug 21, 2013, at 2:58 AM, Mark Thomas wrote:
> On 21/08/2013 01:24, Nick Williams wrote:
>
>> My backup idea is slightly less clean but, IMO, still more clean than adding ASM as a test-time dependency and trying to figure all of that out. I locally compiled fake "weaved" versions of the UnweavedClass (with the modified behavior) and then translated each version into a Java byte array definition. (These are extremely simple on-line, one-method classes, so the byte arrays are relatively short.) I then simply embedded the byte array definitions as static final byte[] fields the test class and replaced the byte code in my fake transformer with those embedded fields' content. I've tested this and it works great.
>>
>> Here's what the embedded byte code for the fake weaved classes looks like. What do you think? Is this acceptable?
>
> Works for me. It is pretty much exactly what I was going to suggest as I
> read your mail.
>
> My only request would be to keep the class (and hence the byte code) as
> short as possible.
Yep! One method that returns a String, has no arguments, and contains one line of code (the return statement) is about as simple as it gets! :-)
Thanks,
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Need guidance for writing unit tests for 55317
Posted by Mark Thomas <ma...@apache.org>.
On 21/08/2013 01:24, Nick Williams wrote:
> My backup idea is slightly less clean but, IMO, still more clean than adding ASM as a test-time dependency and trying to figure all of that out. I locally compiled fake "weaved" versions of the UnweavedClass (with the modified behavior) and then translated each version into a Java byte array definition. (These are extremely simple on-line, one-method classes, so the byte arrays are relatively short.) I then simply embedded the byte array definitions as static final byte[] fields the test class and replaced the byte code in my fake transformer with those embedded fields' content. I've tested this and it works great.
>
> Here's what the embedded byte code for the fake weaved classes looks like. What do you think? Is this acceptable?
Works for me. It is pretty much exactly what I was going to suggest as I
read your mail.
My only request would be to keep the class (and hence the byte code) as
short as possible.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Need guidance for writing unit tests for 55317
Posted by Nick Williams <ni...@nicholaswilliams.net>.
On Aug 20, 2013, at 1:10 PM, Mark Thomas wrote:
> On 20/08/2013 18:47, Nick Williams wrote:
>> My remaining original concern was the best approach for weaving byte
>> code in Tomcat's unit tests, which I detailed in an earlier message.
>
> Use the Weaver to completely replace the byte code of the weaved class
> with the byte code from another class? That way the compiler creates the
> byte code so you know it is valid.
I ran in to a roadblock with this idea. Part of the byte code of a class includes the fully-qualified class name. If I create a class, say UnweavedClass, and replace its byte code in my fake transformer with that of another class, the FQCN changes. This results in a NoClassDefFoundError because the class loader is looking for UnweavenClass in be in the byte code when really some other class is.
My backup idea is slightly less clean but, IMO, still more clean than adding ASM as a test-time dependency and trying to figure all of that out. I locally compiled fake "weaved" versions of the UnweavedClass (with the modified behavior) and then translated each version into a Java byte array definition. (These are extremely simple on-line, one-method classes, so the byte arrays are relatively short.) I then simply embedded the byte array definitions as static final byte[] fields the test class and replaced the byte code in my fake transformer with those embedded fields' content. I've tested this and it works great.
Here's what the embedded byte code for the fake weaved classes looks like. What do you think? Is this acceptable?
/**
* Compiled version of org.apache.tomcat.unittest.weaving.UnweavedClass, except that
* the doMethod method returns "Hello, Weaver #1!".
*/
private static final byte[] WEAVED_REPLACEMENT_1 = new byte[] {
-54, -2, -70, -66, 0, 0, 0, 50, 0, 17, 10, 0, 4, 0, 13, 8, 0, 14, 7, 0, 15, 7, 0, 16,
1, 0, 6, 60, 105, 110, 105, 116, 62, 1, 0, 3, 40, 41, 86, 1, 0, 4, 67, 111, 100, 101,
1, 0, 15, 76, 105, 110, 101, 78, 117, 109, 98, 101, 114, 84, 97, 98, 108, 101, 1, 0, 8,
100, 111, 77, 101, 116, 104, 111, 100, 1, 0, 20, 40, 41, 76, 106, 97, 118, 97, 47, 108,
97, 110, 103, 47, 83, 116, 114, 105, 110, 103, 59, 1, 0, 10, 83, 111, 117, 114, 99,
101, 70, 105, 108, 101, 1, 0, 18, 85, 110, 119, 101, 97, 118, 101, 100, 67, 108, 97,
115, 115, 46, 106, 97, 118, 97, 12, 0, 5, 0, 6, 1, 0, 17, 72, 101, 108, 108, 111, 44,
32, 87, 101, 97, 118, 101, 114, 32, 35, 49, 33, 1, 0, 48, 111, 114, 103, 47, 97, 112,
97, 99, 104, 101, 47, 116, 111, 109, 99, 97, 116, 47, 117, 110, 105, 116, 116, 101,
115, 116, 47, 119, 101, 97, 118, 105, 110, 103, 47, 85, 110, 119, 101, 97, 118, 101,
100, 67, 108, 97, 115, 115, 1, 0, 16, 106, 97, 118, 97, 47, 108, 97, 110, 103, 47, 79,
98, 106, 101, 99, 116, 0, 33, 0, 3, 0, 4, 0, 0, 0, 0, 0, 2, 0, 1, 0, 5, 0, 6, 0, 1, 0,
7, 0, 0, 0, 29, 0, 1, 0, 1, 0, 0, 0, 5, 42, -73, 0, 1, -79, 0, 0, 0, 1, 0, 8, 0, 0, 0,
6, 0, 1, 0, 0, 0, 3, 0, 1, 0, 9, 0, 10, 0, 1, 0, 7, 0, 0, 0, 27, 0, 1, 0, 1, 0, 0, 0,
3, 18, 2, -80, 0, 0, 0, 1, 0, 8, 0, 0, 0, 6, 0, 1, 0, 0, 0, 6, 0, 1, 0, 11, 0, 0, 0, 2,
0, 12
};
/**
* Compiled version of org.apache.tomcat.unittest.weaving.UnweavedClass, except that
* the doMethod method returns "Hello, Weaver #2!".
*/
private static final byte[] WEAVED_REPLACEMENT_2 = new byte[] {
-54, -2, -70, -66, 0, 0, 0, 50, 0, 17, 10, 0, 4, 0, 13, 8, 0, 14, 7, 0, 15, 7, 0, 16,
1, 0, 6, 60, 105, 110, 105, 116, 62, 1, 0, 3, 40, 41, 86, 1, 0, 4, 67, 111, 100, 101,
1, 0, 15, 76, 105, 110, 101, 78, 117, 109, 98, 101, 114, 84, 97, 98, 108, 101, 1, 0, 8,
100, 111, 77, 101, 116, 104, 111, 100, 1, 0, 20, 40, 41, 76, 106, 97, 118, 97, 47, 108,
97, 110, 103, 47, 83, 116, 114, 105, 110, 103, 59, 1, 0, 10, 83, 111, 117, 114, 99,
101, 70, 105, 108, 101, 1, 0, 18, 85, 110, 119, 101, 97, 118, 101, 100, 67, 108, 97,
115, 115, 46, 106, 97, 118, 97, 12, 0, 5, 0, 6, 1, 0, 17, 72, 101, 108, 108, 111, 44,
32, 87, 101, 97, 118, 101, 114, 32, 35, 50, 33, 1, 0, 48, 111, 114, 103, 47, 97, 112,
97, 99, 104, 101, 47, 116, 111, 109, 99, 97, 116, 47, 117, 110, 105, 116, 116, 101,
115, 116, 47, 119, 101, 97, 118, 105, 110, 103, 47, 85, 110, 119, 101, 97, 118, 101,
100, 67, 108, 97, 115, 115, 1, 0, 16, 106, 97, 118, 97, 47, 108, 97, 110, 103, 47, 79,
98, 106, 101, 99, 116, 0, 33, 0, 3, 0, 4, 0, 0, 0, 0, 0, 2, 0, 1, 0, 5, 0, 6, 0, 1, 0,
7, 0, 0, 0, 29, 0, 1, 0, 1, 0, 0, 0, 5, 42, -73, 0, 1, -79, 0, 0, 0, 1, 0, 8, 0, 0, 0,
6, 0, 1, 0, 0, 0, 3, 0, 1, 0, 9, 0, 10, 0, 1, 0, 7, 0, 0, 0, 27, 0, 1, 0, 1, 0, 0, 0,
3, 18, 2, -80, 0, 0, 0, 1, 0, 8, 0, 0, 0, 6, 0, 1, 0, 0, 0, 6, 0, 1, 0, 11, 0, 0, 0, 2,
0, 12
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Need guidance for writing unit tests for 55317
Posted by Nicholas Williams <ni...@nicholaswilliams.net>.
On Tue, Aug 20, 2013 at 1:10 PM, Mark Thomas <ma...@apache.org> wrote:
> On 20/08/2013 18:47, Nick Williams wrote:
>> My remaining original concern was the best approach for weaving byte
>> code in Tomcat's unit tests, which I detailed in an earlier message.
>
> Use the Weaver to completely replace the byte code of the weaved class
> with the byte code from another class? That way the compiler creates the
> byte code so you know it is valid.
>
> Mark
That would be a much simpler approach. Thanks for pointing out the
obvious, Mark! I couldn't see the forest for the trees. I was thinking
way too complex. :-)
I should have a patch soon, now.
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Need guidance for writing unit tests for 55317
Posted by Mark Thomas <ma...@apache.org>.
On 20/08/2013 18:47, Nick Williams wrote:
> My remaining original concern was the best approach for weaving byte
> code in Tomcat's unit tests, which I detailed in an earlier message.
Use the Weaver to completely replace the byte code of the weaved class
with the byte code from another class? That way the compiler creates the
byte code so you know it is valid.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Need guidance for writing unit tests for 55317
Posted by Nick Williams <ni...@nicholaswilliams.net>.
On Aug 20, 2013, at 12:41 PM, Christopher Schultz wrote:
> Nick,
>
> On 8/20/13 1:25 PM, Christopher Schultz wrote:
>> tcnative can be built on Max OS X like this:
>>
>> $ cd $CATALINA_HOME/bin
>> $ tar xzf tomcat-native.tar.gz
>> $ cd tomcat-native-*-src/jni/native
>> $ ./configure --with-apr=/usr/bin/apr-1-config --with-ssl
>> --with-java-home=`/usr/libexec/java_home`
>>
>> At this point, configure chokes on my system because it's trying to find
>> 'cc' under Xcode.app and I'm not sure where it's sniffing that directory
>> base from. Maybe you'll have better luck. I'll reply if I figure it out.
>
> Okay, it seems that apr-1-config is giving the wrong path for 'cc' to
> configure. I'm investigating…
I don't have a particular need to build this, especial not on Mac OS X right now. I'm working in Windows 7.
My remaining original concern was the best approach for weaving byte code in Tomcat's unit tests, which I detailed in an earlier message.
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Need guidance for writing unit tests for 55317
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Nick,
On 8/20/13 1:41 PM, Christopher Schultz wrote:
> Nick,
>
> On 8/20/13 1:25 PM, Christopher Schultz wrote:
>> tcnative can be built on Max OS X like this:
>>
>> $ cd $CATALINA_HOME/bin
>> $ tar xzf tomcat-native.tar.gz
>> $ cd tomcat-native-*-src/jni/native
>> $ ./configure --with-apr=/usr/bin/apr-1-config --with-ssl
>> --with-java-home=`/usr/libexec/java_home`
>>
>> At this point, configure chokes on my system because it's trying to find
>> 'cc' under Xcode.app and I'm not sure where it's sniffing that directory
>> base from. Maybe you'll have better luck. I'll reply if I figure it out.
>
> Okay, it seems that apr-1-config is giving the wrong path for 'cc' to
> configure. I'm investigating...
Okay, you can simply trump apr-1-config's (incorrect) path for cc like this:
$ CC=/usr/bin/gcc ./configure --with-apr=/usr/bin/apr-1-config
--with-ssl --with-java-home=`/usr/libexec/java_home`
Unfortunately, make then chokes with a similar problem, and make doesn't
want to allow you to override CC on the command-line.
Instead, I had to hack /usr/share/apr-1/build-1/apr_rules.mk and modify
the existing CC definition:
CC=/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc
... to instead point to where cc actually lives:
CC=/usr/bin/gcc
I had to re-run ./configure (as above, including the CC=... stuff) and
now make is complaining about something else:
$ make
/bin/sh /usr/share/apr-1/build-1/libtool --silent --mode=compile
/usr/bin/gcc -g -Os -pipe -DHAVE_CONFIG_H -DDARWIN
-DSIGPROCMASK_SETS_THREAD_MASK -g -O2 -DHAVE_OPENSSL
-I/Users/chris/packages/apache-tomcat-7.0.42/bin/temp/tomcat-native-1.1.27-src/jni/native/include
-I/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/include/darwin
-I/usr/include/apr-1 -o src/address.lo -c src/address.c && touch
src/address.lo
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'
make[1]: *** [src/address.lo] Error 1
make: *** [all-recursive] Error 1
:(
-chris
Re: Need guidance for writing unit tests for 55317
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Nick,
On 8/20/13 1:25 PM, Christopher Schultz wrote:
> tcnative can be built on Max OS X like this:
>
> $ cd $CATALINA_HOME/bin
> $ tar xzf tomcat-native.tar.gz
> $ cd tomcat-native-*-src/jni/native
> $ ./configure --with-apr=/usr/bin/apr-1-config --with-ssl
> --with-java-home=`/usr/libexec/java_home`
>
> At this point, configure chokes on my system because it's trying to find
> 'cc' under Xcode.app and I'm not sure where it's sniffing that directory
> base from. Maybe you'll have better luck. I'll reply if I figure it out.
Okay, it seems that apr-1-config is giving the wrong path for 'cc' to
configure. I'm investigating...
-chris
Re: Need guidance for writing unit tests for 55317
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Nick,
On 8/20/13 11:15 AM, Nick Williams wrote:
>
> On Aug 20, 2013, at 10:12 AM, Christopher Schultz wrote:
>
>> Mark,
>>
>> On 8/20/13 9:25 AM, Mark Thomas wrote:
>>> On 20/08/2013 14:13, Nick Williams wrote:
>>>> I'm working on implementing bugzilla 55317. It's a pretty important
>>>> change (weaving) to a pretty import class (WebappClassLoader), so it
>>>> obviously needs some unit tests. However, I need some guidance:
>>>>
>>>> 1) I've never gotten all the existing tests to pass on my machine.
>>>> Last time I ran them it took 45 minutes (holy crap) and about 1/3 of
>>>> them failed. This is obviously something wrong with my configuration
>>>> and not with Tomcat. I'd like to avoid running all tests for this
>>>> reason and only run the particular tests I'm working on. How would I
>>>> do this? Is this even possible with Ant?
>>>
>>> ant test -Dtest.entry=org.apache.catalina.TestClassToExecute
>>>
>>> svn co ...
>>> ant clean test
>>>
>>> should work on Windows, Linux and OSX for all three connectors.
>>
>> 1/3 of the tests will fail if the native connector hasn't been built.
>> Could that be your problem, Nick?
>
> If the native connector doesn't get built by running "ant clean
> test", then yes, that could very well be my problem.
It does not.
tcnative can be built on Max OS X like this:
$ cd $CATALINA_HOME/bin
$ tar xzf tomcat-native.tar.gz
$ cd tomcat-native-*-src/jni/native
$ ./configure --with-apr=/usr/bin/apr-1-config --with-ssl
--with-java-home=`/usr/libexec/java_home`
At this point, configure chokes on my system because it's trying to find
'cc' under Xcode.app and I'm not sure where it's sniffing that directory
base from. Maybe you'll have better luck. I'll reply if I figure it out.
After ./configure, you ought to be able to just "make" and wait a minute
or two. Remember that you get a few libraries and a few links. It's best
to copy the links as links into $TOMCAT_HOME/bin or wherever you want to
put them. Then, remember to set java.library.path when launching
anything Java-related.
-chris
Re: Need guidance for writing unit tests for 55317
Posted by Nick Williams <ni...@nicholaswilliams.net>.
On Aug 20, 2013, at 10:12 AM, Christopher Schultz wrote:
> Mark,
>
> On 8/20/13 9:25 AM, Mark Thomas wrote:
>> On 20/08/2013 14:13, Nick Williams wrote:
>>> I'm working on implementing bugzilla 55317. It's a pretty important
>>> change (weaving) to a pretty import class (WebappClassLoader), so it
>>> obviously needs some unit tests. However, I need some guidance:
>>>
>>> 1) I've never gotten all the existing tests to pass on my machine.
>>> Last time I ran them it took 45 minutes (holy crap) and about 1/3 of
>>> them failed. This is obviously something wrong with my configuration
>>> and not with Tomcat. I'd like to avoid running all tests for this
>>> reason and only run the particular tests I'm working on. How would I
>>> do this? Is this even possible with Ant?
>>
>> ant test -Dtest.entry=org.apache.catalina.TestClassToExecute
>>
>> svn co ...
>> ant clean test
>>
>> should work on Windows, Linux and OSX for all three connectors.
>
> 1/3 of the tests will fail if the native connector hasn't been built.
> Could that be your problem, Nick?
If the native connector doesn't get built by running "ant clean test", then yes, that could very well be my problem.
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Need guidance for writing unit tests for 55317
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 8/20/13 9:25 AM, Mark Thomas wrote:
> On 20/08/2013 14:13, Nick Williams wrote:
>> I'm working on implementing bugzilla 55317. It's a pretty important
>> change (weaving) to a pretty import class (WebappClassLoader), so it
>> obviously needs some unit tests. However, I need some guidance:
>>
>> 1) I've never gotten all the existing tests to pass on my machine.
>> Last time I ran them it took 45 minutes (holy crap) and about 1/3 of
>> them failed. This is obviously something wrong with my configuration
>> and not with Tomcat. I'd like to avoid running all tests for this
>> reason and only run the particular tests I'm working on. How would I
>> do this? Is this even possible with Ant?
>
> ant test -Dtest.entry=org.apache.catalina.TestClassToExecute
>
> svn co ...
> ant clean test
>
> should work on Windows, Linux and OSX for all three connectors.
1/3 of the tests will fail if the native connector hasn't been built.
Could that be your problem, Nick?
-chris
Re: Need guidance for writing unit tests for 55317
Posted by Jeremy Boynes <jb...@apache.org>.
On Aug 20, 2013, at 7:42 AM, Nick Williams <ni...@nicholaswilliams.net> wrote:
>
> Well, yea. I had figured that part out. :-) I just didn't articulate my question well enough.
>
> The first step is obviously loading the class through the WACL through the unit test (so this has to be a class not already loaded). I assume I'll figure this part out reading through the existing WACL tests. But the key is *how* to use weaving in the context of the Tomcat unit tests. The way I see it I essentially have two options (though I may be overlooking something):
>
> 1) Manually manipulate the bytes. This takes great expertise and is ripe for failure. Not a big fan of the idea.
> 2) Introduce an additional test-time dependency on something like ASM. This is probably the safest route, but it introduces an additional test-time dependency. I don't know how amenable y'all are to that.
You only need to test that the weaver is called correctly, not that it actually weaves anything. You could have a stub weaver that just captures that it was called and verify that is what you expect. EasyMock might help here.
Re: Need guidance for writing unit tests for 55317
Posted by Nick Williams <ni...@nicholaswilliams.net>.
On Aug 20, 2013, at 8:25 AM, Mark Thomas wrote:
> On 20/08/2013 14:13, Nick Williams wrote:
>> I'm working on implementing bugzilla 55317. It's a pretty important
>> change (weaving) to a pretty import class (WebappClassLoader), so it
>> obviously needs some unit tests. However, I need some guidance:
>>
>> 1) I've never gotten all the existing tests to pass on my machine.
>> Last time I ran them it took 45 minutes (holy crap) and about 1/3 of
>> them failed. This is obviously something wrong with my configuration
>> and not with Tomcat. I'd like to avoid running all tests for this
>> reason and only run the particular tests I'm working on. How would I
>> do this? Is this even possible with Ant?
>
> ant test -Dtest.entry=org.apache.catalina.TestClassToExecute
Ahhh. Thanks! I somehow missed that when reading BUILDING.txt. Or, rather, more likely forgot, since I read it several months ago.
> svn co ...
> ant clean test
>
> should work on Windows, Linux and OSX for all three connectors.
>
> There are some tests that are 'fragile'. They need some time spent on
> them to figure out if they fail because the tests have a subtle timing
> bug (like the one I fixed this morning) or if the code does.
>
> One or two failures wouldn't surprise me. 1/3 failing suggests a problem
> with the environment.
Agreed. The environment is Windows 7 Pro SP 1 64-bit running Java 8 beta 64-bit. Could be a Java 8 issue. Could be a setup issue. Could be a number of other things. I'll try to troubleshoot it more once Java 8 is more stable. FWIW, only one or two tests failed on Java 7 64-bit on my Mac OS X Lion environment.
>> 2) I'm not sure exactly how to approach testing this particular
>> feature. It's obviously not completely straightforward. This is
>> weaving we're talking about, so somehow I have to load a class and
>> weave it to test that it's properly woven. Suggestions on where to
>> get started / what tools to use? As much as I hate it, part of me is
>> saying that functional testing is really the best course here, in
>> which case this is all moot.
>
> Using weaving to add functionality that is easily tested to see if it is
> present?
Well, yea. I had figured that part out. :-) I just didn't articulate my question well enough.
The first step is obviously loading the class through the WACL through the unit test (so this has to be a class not already loaded). I assume I'll figure this part out reading through the existing WACL tests. But the key is *how* to use weaving in the context of the Tomcat unit tests. The way I see it I essentially have two options (though I may be overlooking something):
1) Manually manipulate the bytes. This takes great expertise and is ripe for failure. Not a big fan of the idea.
2) Introduce an additional test-time dependency on something like ASM. This is probably the safest route, but it introduces an additional test-time dependency. I don't know how amenable y'all are to that.
>> 3) I'm not even sure how to approach testing in Tomcat in general.
>> I've seen a lot of "unit tests" that look more like integration
>> tests, at least according to my training. Are there general
>> guidelines for writing "correct" unit tests in Tomcat, or is in
>> generally accepted as long as it passes?
>
> Ideally, they should look like unit tests but a lot of the Tomcat code
> is not suited to that style of testing. There is nothing wrong with a
> little refactoring to aid testing but obviously there is a balance to
> strike.
>
> Any test that a) provides value and b) passes is likely to be accepted.
Thanks. That helps.
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Need guidance for writing unit tests for 55317
Posted by Mark Thomas <ma...@apache.org>.
On 20/08/2013 14:13, Nick Williams wrote:
> I'm working on implementing bugzilla 55317. It's a pretty important
> change (weaving) to a pretty import class (WebappClassLoader), so it
> obviously needs some unit tests. However, I need some guidance:
>
> 1) I've never gotten all the existing tests to pass on my machine.
> Last time I ran them it took 45 minutes (holy crap) and about 1/3 of
> them failed. This is obviously something wrong with my configuration
> and not with Tomcat. I'd like to avoid running all tests for this
> reason and only run the particular tests I'm working on. How would I
> do this? Is this even possible with Ant?
ant test -Dtest.entry=org.apache.catalina.TestClassToExecute
svn co ...
ant clean test
should work on Windows, Linux and OSX for all three connectors.
There are some tests that are 'fragile'. They need some time spent on
them to figure out if they fail because the tests have a subtle timing
bug (like the one I fixed this morning) or if the code does.
One or two failures wouldn't surprise me. 1/3 failing suggests a problem
with the environment.
> 2) I'm not sure exactly how to approach testing this particular
> feature. It's obviously not completely straightforward. This is
> weaving we're talking about, so somehow I have to load a class and
> weave it to test that it's properly woven. Suggestions on where to
> get started / what tools to use? As much as I hate it, part of me is
> saying that functional testing is really the best course here, in
> which case this is all moot.
Using weaving to add functionality that is easily tested to see if it is
present?
> 3) I'm not even sure how to approach testing in Tomcat in general.
> I've seen a lot of "unit tests" that look more like integration
> tests, at least according to my training. Are there general
> guidelines for writing "correct" unit tests in Tomcat, or is in
> generally accepted as long as it passes?
Ideally, they should look like unit tests but a lot of the Tomcat code
is not suited to that style of testing. There is nothing wrong with a
little refactoring to aid testing but obviously there is a balance to
strike.
Any test that a) provides value and b) passes is likely to be accepted.
As an aside, I'm fairly sure there is a huge amount of code duplication
in the tests.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org