Steve Loughran wrote:
> Frank Wilson wrote:
>>> If you like your testing, it's very good for automating bringing up
>>> stuff, running tests and tearing them down, which you can then do direct
>>> from your JUnit test run.
>> Yes we plan to do system testing using Smartfrog. You seem to say that I
>> can bring stuff up and tear stuff down from a JUnit test run. I was thinking
>> of
>> embedding Smartfrog in my JUnit tests, although I am not too sure how to do
>> it.
>> My first thought was to look at the ant "deploy" task for guidance on how to
>> control
>> Smartfrog from within java. Is this a sensible approach?
>> Do you have any tips or pointers on how to do this?
>
> yes, you need to grab the testharness JAR which I think we distribute,
> but whose source you should grab from SVN anyway. There is a class,
> core/testharness/src/org/smartfrog/test/DeployingTestBase.java , which
> extends TestCase and which provides everything you need to talk to a
> SmartFrog daemon, deploy a test then wait for it to finish, while
> fielding lifecycle events sent back over RMI.
>
> There is more in
> core/smartfrog/src/org/smartfrog/services/assertions/events/TestEventSink.java
>
> , where something can deploy an app, wait for events and field failures
> back up to the caller so that you get the remote stack trace in your
> junit formatted results -something hudson likes too.
>
> in your junit code every test method can deploy something; what they do
> is up to them
>
> package org.smartfrog.extras.hadoop.cluster.test.system.health;
>
> import org.smartfrog.test.DeployingTestBase;
>
>
> public class SystemHealthTest extends DeployingTestBase {
I should mention a couple more things here, which you can see if you
browse into the code of DeployingTestBase, SmartFrogTestBase and TestHelper
1. the target SF daemon to talk to is localhost, but it can be changed
by starting junit with the property test.smartfrog.hostname set to a
different hostname
2. the method Prim deployExpectingSuccess(String testURL, String
appName) deploys any path you specify as an application on the targeted
host; if you set the application field to the returned value via
setApplication(), it will be terminated automatically on test teardown.
3. you can cast the Prim to whatever interfaces your application
supports, locate children etc, and make any RMI operation you want to.
Just bear in mind that if the far end sends back an exception you can't
deserialize (like some JDBC-driver specific error), the stack trace will
be of no use. The exceptions saved in the TerminationRecord deliberately
convert any exception that isn't in a java., javax. or org.smartfrog.
package to avoid this little problem.
-steve
------------------------------------------------------------------------------
_______________________________________________
Smartfrog-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/smartfrog-users
