Setup to test verticles / busmods?

[Joern Bernhardt]

Hi there,

I want to create a little busmod and write tests for it. My question is: How do I set everything up to test it? What things do I have to do, how can I run the tests, etc.

From the looks of (for example) https://github.com/vert-x/mod-work-queue, there are thousand of gradle files with millions of properties, tasks and whatever all that stuff means. I don't know what I'd need to do, which files I have to copy / change to get it working. Is there any documentation, what the minimum requirements are? It would be nice to do "./mk test" (or "./gradle test") and have the tests run.
I could find this topic to make testing itself easier: https://groups.google.com/forum/?fromgroups#!topic/vertx/-g4RXVsmo8E
Does this mean I don't need all the gradle stuff itself and be able to start it right from my IDE? If so, how would that work? If I intend to publish the busmod, I guess using gradle would be the better strategy, so one could distribute the busmod with all of its tests?

It would be great if there were some more docs about testing busmods, testing strategies and the setup for publishing a busmod with included tests - just like the "official" busmods.

Thanks,
Joern

[Tim Fox]

On Saturday, July 28, 2012 1:07:55 PM UTC+1, Joern Bernhardt wrote:

Hi there,

I want to create a little busmod and write tests for it. My question is: How do I set everything up to test it? What things do I have to do, how can I run the tests, etc.

The easiest way to do this is just to copy one of the module projects, e.g. mod-mongo-persistor etc.

 

From the looks of (for example) https://github.com/vert-x/mod-work-queue, there are thousand of gradle files with millions of properties, tasks and whatever all that stuff means. I don't know what I'd need to do, which files I have to copy / change to get it working.

Just put your src code in the src/main directory, and your tests in the src/test directory.

src/test/java contains the JUnit tests - these are just proxies which call the actual tests in src/tests/resources - the tests are just verticles which run in the container and call your module. 

It's all pretty simple and self-explanatory (I think).

 

Is there any documentation, what the minimum requirements are? It would be nice to do "./mk test" (or "./gradle test") and have the tests run.

Yes, ./mk test should work if you copy the standard module project.

./mk dist creates the mod.zip

 

I could find this topic to make testing itself easier: https://groups.google.com/forum/?fromgroups#!topic/vertx/-g4RXVsmo8E
Does this mean I don't need all the gradle stuff itself and be able to start it right from my IDE? If so, how would that work?

I don't know - I don't use Gradle from an IDE (actually I'm pretty much a Gradle newb myself)

 

If I intend to publish the busmod, I guess using gradle would be the better strategy, so one could distribute the busmod with all of its tests?

To publish a module to the public repository. First build it (use ./mk dist if you're using the standard Gradle module build), then tell me and I'll put it in the repo. Either that or send a pull request to the module repository.

BTW you don't have to use the Gradle build for building a module if you don't want. You can use whatever build system you prefer. As long as you can produce a mod.zip as describe in the modules manual, that can go in the module repository. 

[Tim Fox]

I'll put together a wiki page explaining how people can adapt one of the standard module builds to make their own module, and how to submit it to the public repo.

[Brian Lalor]

On Jul 29, 2012, at 8:42 AM, Tim Fox wrote:

Just put your src code in the src/main directory, and your tests in the src/test directory.

When I did the AMQP busmod I found that I had to use the same package structure as the built-in busmods.  Is that still the case?

[Tim Fox]

Probably not. The new modules are based on the new Gradle build - the old built in modules were using the ant build.

But, fundamentally you can use whatever build you want. As long as the output is a valid mod.zip it doesn't matter. I recommend using the standard Gradle module builds (e.g. mod-mongo-persistor) only as a convenience - just copy the repo, substitute your source and tests, and you should be going in minutes.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To post to this group, send an email to ve...@googlegroups.com.
To unsubscribe from this group, send email to vertx+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/vertx?hl=en-GB.

[Brian Lalor]

On Jul 29, 2012, at 9:27 AM, Tim Fox wrote:

Probably not. The new modules are based on the new Gradle build - the old built in modules were using the ant build.

But, fundamentally you can use whatever build you want. As long as the output is a valid mod.zip it doesn't matter. I recommend using the standard Gradle module builds (e.g. mod-mongo-persistor) only as a convenience - just copy the repo, substitute your source and tests, and you should be going in minutes.

It wasn't build-related (I built the AMQP mod with Maven); it was about the fact that the support classes for the tests used some package-protected class stuff, I think.  I don't recall the exact problem, but it was clear that the integration testing support stuff wasn't designed for real extensibility or use outside of the "system" package hierarchy.

[Tim Fox]

The test framework stuff can certainly be improved, but you've always been able to use it outside the rest of the framework, that hasn't changed.

[Joern Bernhardt]

So I copied the mongo mod, changed some files (no mongo dependency in build.gradle, changed mod.json). I still have some trouble with including some Scala sources, but this seems to be gradle or classpath related. It compiles but the tests won't run because of a NoClassDefFoundError.

My real problem with the testing framework is/was the following: Which files are getting run by gradle? And which files are run because of the test-app. I guess it works like this, please correct me if I'm wrong here...

Gradle runs these files as JUnit tests:

- org.vertx.mods.tests.JavaPersistorTest

- org.vertx.mods.tests.JavaScriptPersistorTest

The testing framework calls vertx.mods.tests.verticles.java.TestClient from JavaPersistorTest and test_client.js from JavaScriptPersistorTest. All @Test functions in JavaPersistorTest / JavaScriptPersistorTest call one of the methods in the TestClient.java / test_client.js files. If I would add another method in TestClient.java or test_client.js I would need to add a test to the above mentioned JUnit files as well.

I raised the question initially because the whole testing is not really self-explanatory for me. ;)

Without understanding the basics of gradle and the testing framework, this looked like magic to me...

Thanks,

Joern

[Tim Fox]

On 30/07/12 12:45, Joern Bernhardt wrote:
> So I copied the mongo mod, changed some files (no mongo dependency in
> build.gradle, changed mod.json). I still have some trouble with
> including some Scala sources, but this seems to be gradle or classpath
> related. It compiles but the tests won't run because of a
> NoClassDefFoundError.
>
> My real problem with the testing framework is/was the following: Which
> files are getting run by gradle? And which files are run because of
> the test-app. I guess it works like this, please correct me if I'm
> wrong here...
> Gradle runs these files as JUnit tests:
> - org.vertx.mods.tests.JavaPersistorTest
> - org.vertx.mods.tests.JavaScriptPersistorTest

Yes those are the actual JUnit tests which get run. They are basically
proxies which start up the "real" test (which is just a Verticle) in the
vert.x container, run the tests, and report the results back.

>
> The testing framework calls vertx.mods.tests.verticles.java.TestClient
> from JavaPersistorTest and test_client.js from JavaScriptPersistorTest.

Yes these are the actual verticles which run in the container/

> All @Test functions in JavaPersistorTest / JavaScriptPersistorTest
> call one of the methods in the TestClient.java / test_client.js files.
> If I would add another method in TestClient.java or test_client.js I
> would need to add a test to the above mentioned JUnit files as well.

Yes you would.

A couple of people have done some work (see recent discussions on the
google group) to simplify this, but for now you need to remember to add
a matching method name in both the proxy and the verticle.

>
> I raised the question initially because the whole testing is not
> really self-explanatory for me. ;)
> Without understanding the basics of gradle and the testing framework,
> this looked like magic to me...

I hear you. Like I've said before the test framework needs to be
simplified - just haven't got around to it yet.

Regarding Gradle- I agree, I find much of it "magic" too :(

>
> Thanks,
> Joern
>
>
> On Sunday, July 29, 2012 4:51:15 PM UTC+2, Tim Fox wrote:
>
> The test framework stuff can certainly be improved, but you've
> always been able to use it outside the rest of the framework, that
> hasn't changed.
>
> On Sunday, July 29, 2012 3:19:45 PM UTC+1, blalor wrote:
>
> On Jul 29, 2012, at 9:27 AM, Tim Fox wrote:
>
>> Probably not. The new modules are based on the new Gradle
>> build - the old built in modules were using the ant build.
>>
>> But, fundamentally you can use whatever build you want. As
>> long as the output is a valid mod.zip it doesn't matter. I
>> recommend using the standard Gradle module builds (e.g.
>> mod-mongo-persistor) only as a convenience - just copy the
>> repo, substitute your source and tests, and you should be
>> going in minutes.
>
> It wasn't build-related (I built the AMQP mod with Maven); it
> was about the fact that the support classes for the tests used
> some package-protected class stuff, I think. I don't recall
> the exact problem, but it was clear that the integration
> testing support stuff wasn't designed for real extensibility
> or use outside of the "system" package hierarchy.
>

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.

> To view this discussion on the web, visit
> https://groups.google.com/d/msg/vertx/-/69EKOX99QjwJ.

> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.

--
Tim Fox

Vert.x - effortless polyglot asynchronous application development
http://vertx.io
twitter:@timfox

[Joern Bernhardt]

I was a little bit too quick to assume everything would be working fine and my problem is just scala related. If I try to run the JUnit tests of mod-mongo-persistor from within Eclipse IDE, I get the following exception:

creating verticle vertx.mods.tests.verticles.java.TestClient
creating verticle org.vertx.mods.MongoPersistor
Jul 31, 2012 11:14:53 PM org.vertx.java.core.logging.impl.JULLogDelegate error
Schwerwiegend: Failed to create verticle
java.lang.IllegalStateException: Do not add application classes to the vert.x classpath
    at org.vertx.java.deploy.impl.java.JavaVerticleFactory.createVerticle(JavaVerticleFactory.java:83)
    at org.vertx.java.deploy.impl.VerticleManager$9.run(VerticleManager.java:615)
    at org.vertx.java.core.impl.Context$2.run(Context.java:118)
    at org.vertx.java.core.impl.Context$1.run(Context.java:108)
    at org.vertx.java.core.impl.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:90)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at java.lang.Thread.run(Thread.java:722)

Jul 31, 2012 11:14:53 PM org.vertx.java.core.logging.impl.JULLogDelegate info
Information: Starting test: testPersistor

Using Gradle (./mk test) works, but running the JUnit tests without Gradle seems to cause problems. Any suggestions?

Thanks,
Joern

> vertx+unsubscribe@googlegroups.com.

[Tim Fox]

I rarely run tests from an IDE, so this is not something I have tried.

> <https://groups.google.com/d/msg/vertx/-/69EKOX99QjwJ>.

> > To post to this group, send an email to ve...@googlegroups.com

> <mailto:ve...@googlegroups.com>.

> > To unsubscribe from this group, send email to

> > vertx+un...@googlegroups.com
> <mailto:vertx%2Bunsu...@googlegroups.com>.

> > For more options, visit this group at
> > http://groups.google.com/group/vertx?hl=en-GB

> <http://groups.google.com/group/vertx?hl=en-GB>.

>
>
> --
> Tim Fox
>
> Vert.x - effortless polyglot asynchronous application development
> http://vertx.io
> twitter:@timfox
>

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/vertx/-/-AlaLDJ2JCsJ.

> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to

> vertx+un...@googlegroups.com.

[Pid]

The problem is that IDEs combine the classpath of src/main and src/test,
which causes vert.x to see the application stuff on its own classpath.

The gradle build, as the ant build did, modify the classpath presented
to the unit tests to address this.


The only way around this that will work to enable unit tests in an IDE
OOTB is to provide a separate classloader to either the verticle factory
or to the embedded vert.x instance.

I've experimented with a few approaches to achieve this but they are all
pretty ugly. The alternative, perhaps, is to use a vert.x installation
for the tests, but that's also a PITA.

Another alternative I'm trying out is to overload a VerticleFactory,
launching tests with the prefix "test:" on the main class name, and
remove or modify the classloader separation issue.

Right now, stick with the Gradle test command. You can get it to run a
subset of the tests by setting -Dtest.single=<test-class-name-pattern>


See 23.12.2. System properties:

http://www.gradle.org/docs/current/userguide/java_plugin.html


p

> <https://groups.google.com/d/msg/vertx/-/69EKOX99QjwJ>.

> > To post to this group, send an email to ve...@googlegroups.com

> <mailto:ve...@googlegroups.com>.

> > To unsubscribe from this group, send email to

> > vertx+un...@googlegroups.com
> <mailto:vertx%2Bunsu...@googlegroups.com>.

> > For more options, visit this group at
> > http://groups.google.com/group/vertx?hl=en-GB

> <http://groups.google.com/group/vertx?hl=en-GB>.

>
>
> --
> Tim Fox
>
> Vert.x - effortless polyglot asynchronous application development
> http://vertx.io
> twitter:@timfox
>

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/vertx/-/-AlaLDJ2JCsJ.

> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to

> vertx+un...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.


--

[key:62590808]

[Joern Bernhardt]

I even tried running junit from the command line, which resulted in the same error (I used this command in the build-dir: CLASSPATH="$(echo $(ls deps/test/*.jar -m) | sed 's/, /:/g'):classes/main:classes/test" junit org.vertx.mods.tests.JavaPersistorTest). Thanks to you I can see why this fails - obviously, I put everything in the same classpath. But how could I do it differently?

Since I cannot get Scala to work with Gradle, I don't really have the possibility to test the things I've done so far... :(

Regarding the scala problem, maybe someone has a clue? I added four lines to build.gradle:
apply plugin 'scala' // after all those other apply plugins.
scalaTools "org.scala-lang:scala-compiler:$scalaVersion" // inside the dependencies { ... } block
scalaTools "org.scala-lang:scala-library:$scalaVersion" // inside the dependencies { ... } block
compile "org.scala-lang:scala-library:$scalaVersion" // inside the dependencies { ... } block

If I have my JUnit proxy written in Scala, compilation works, but I get "initializationError" in my Gradle test results with "java.lang.NoClassDefFoundError: scala/ScalaObject". If I write it in Java and let it reside in src/test/java, compilation doesn't work, since the proxy cannot find my scala test classes (which are not yet compiled). So after putting the Java JUnit proxy in src/test/scala and let scalac handle compilation, Gradle throws an error, because of a missing dependency regarding class org.jboss.netty.buffer.ChannelBuffer. I don't use/import it in any of my scala classes, so I wonder why it doesn't complain when I run Gradle on the mod-mongo-persistor. I added the line 'compile "io.netty:netty:3.5.0.Final"' in the build.gradle file under dependencies. After that, compilation works, but I get an initializationError in the test results: java.lang.NoClassDefFoundError: org/jboss/netty/util/TimerTask.

I'm feeling like this: http://assets0.ordienetworks.com/images/user_photos/1245619/52e11a8d43b6ba18cac49cfc6c069983_fullsize.jpg

 

>     > vertx+unsubscribe@googlegroups.com
>     <mailto:vertx%2Bunsubscribe@googlegroups.com>.

>     > For more options, visit this group at
>     > http://groups.google.com/group/vertx?hl=en-GB
>     <http://groups.google.com/group/vertx?hl=en-GB>.
>
>
>     --
>     Tim Fox
>
>     Vert.x - effortless polyglot asynchronous application development
>     http://vertx.io
>     twitter:@timfox
>
> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/vertx/-/-AlaLDJ2JCsJ.
> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to

> vertx+unsubscribe@googlegroups.com.

[Tim Fox]

No-one is forcing you to use Gradle for your module build - you can use whatever build tool you feel comfortable with. Actually I have some sympathy for you as I am rapidly getting to the point of hating Gradle (for me, favourite is ant, but this is subjective of course).

So, I recommend using Maven, ant, whatever if you're more comfortable with that.

[Joern Bernhardt]

On Wednesday, August 1, 2012 10:53:29 AM UTC+2, Tim Fox wrote:

No-one is forcing you to use Gradle for your module build - you can use whatever build tool you feel comfortable with. Actually I have some sympathy for you as I am rapidly getting to the point of hating Gradle (for me, favourite is ant, but this is subjective of course).

So, I recommend using Maven, ant, whatever if you're more comfortable with that.

I actually tried to use the old ant build.xml from the mod-mongo-persistor, but I didn't finish it yet. I could almost always have my IDE do all the build-related stuff for me, so I never really bothered to learn any build tool. Ant might be more straightforward with less "magic" than Gradle, but if I really have to learn a build tool now, why shouldn't I start with Gradle? I want to understand what's going on in vert.x, since our start-up project relies heavily on it... :)

 

[Brian Lalor]

On Aug 1, 2012, at 4:53 AM, Tim Fox <timv...@gmail.com> wrote:

No-one is forcing you to use Gradle for your module build - you can use whatever build tool you feel comfortable with. Actually I have some sympathy for you as I am rapidly getting to the point of hating Gradle (for me, favourite is ant, but this is subjective of course).

So, I recommend using Maven, ant, whatever if you're more comfortable with that.

I haven't touched the AMQP busmod since I wrapped it up a couple of months ago, but I built that using Maven.  The compilation and dependency management are contained entirely in pom.xml, and the recipe for packaging the module is contained in a separate assembly file in src/main/assembly.  It's verbose in the usual Maven way, but it's quite simple and there's no magic. I haven't updated this now that Vert.x is available in the Maven central repository, but it could serve as a starting point.

https://github.com/blalor/vert.x-busmod-amqp

[Brian Lalor]

On Jul 29, 2012, at 10:51 AM, Tim Fox <timv...@gmail.com> wrote:

On Sunday, July 29, 2012 3:19:45 PM UTC+1, blalor wrote:

It wasn't build-related (I built the AMQP mod with Maven); it was about the fact that the support classes for the tests used some package-protected class stuff, I think.  I don't recall the exact problem, but it was clear that the integration testing support stuff wasn't designed for real extensibility or use outside of the "system" package hierarchy.

The test framework stuff can certainly be improved, but you've always been able to use it outside the rest of the framework, that hasn't changed.

This is what happens when I change my package structure from

org.vertx.java.busmods.amqp to org.bravo5.vertx.java.busmods.amqp, without any other changes. The tests execute fine, otherwise.

Aug  1 17:58:40 [FINE   ] org.vertx.java.core.logging.impl.JULLogDelegate debug - Deploying name : deployment-c582b304-4dc2-4144-bb90-5853af73603d main: org.bravo5.vertx.java.busmods.amqp.AmqpBridge instances: 1 

Aug  1 17:58:40 [SEVERE ] org.vertx.java.core.logging.impl.JULLogDelegate error - Failed to create verticle 

java.lang.IllegalStateException: Do not add application classes to the vert.x classpath

at org.vertx.java.deploy.impl.java.JavaVerticleFactory.createVerticle(JavaVerticleFactory.java:80)

at org.vertx.java.deploy.impl.VerticleManager$9.run(VerticleManager.java:602)

at org.vertx.java.core.impl.Context$2.run(Context.java:118)

[Tim Fox]

Yes, your verticle can't be on the main classpath (otherwise you could
share state between verticle instances using static).

In the gradle mod build, Tim Yates removed it from the cp as follows:

https://github.com/vert-x/mod-mongo-persistor/blob/master/build.gradle#L80

Don't know how you'd do that in Maven.

On 01/08/12 23:04, Brian Lalor wrote:
> On Jul 29, 2012, at 10:51 AM, Tim Fox <timv...@gmail.com

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.