Doh... just realized I didn't commit the correct relative path of the parent pom in all the children.... ughh... I'll do that when I get home tonight, don't want to commit to the project from work (pulled it down to demo it today to the point haired folks)
I did look at using cargo underneath, but since it tends to spawn separate jvms, and want wars instead of exploded dirs for most of the servers, I went with direct jetty -- perhaps I didn't investigate enough. And the big benefit of the library is that there are no extra steps, aside from the initial app setup/pom editing. You can simply right click on a file and "debug as testng test" I'm kinda following a hacky actor pattern for the individual services ...should probably clean that up some... used by the tests (app server and web driver instances) and am thinking of trying to keep them resident somewhere in memory in eclipse at all times, rebuilding them when the jdk 1.4 debug reloading wont work due to method signature change, as that'd make testing very fast, after having already made it very easy. Though at some point I might look at glassfish or resin if there is interest (any webcontainer that doesn't mind being started in debug mode by eclipse). I will dig in webby tonight to look at it's capabilities though. On Tue, Jul 19, 2011 at 12:21 PM, Jason van Zyl <ja...@sonatype.com> wrote: > You might want to look at Sonatype's m2eclipse-webby[1] for a very easy way > to startup web containers. It would probably be relatively straight forward > to integrate your code for runnings tests. > > Webby leverages Cargo to start/stop containers and we've added debugging > support, resource filtering and WAR overlay support. > > > https://docs.sonatype.org/display/M2ECLIPSE/Integration+with+Maven+WAR+Plugin > > On Jul 19, 2011, at 3:11 PM, Rex Hoffman wrote: > > > On peripherally maven-dev related, but as thought leaders, I hope you > guys > > would take interest. > > > > > > So I've been aggravated that I've had to start a web app up before > running a > > test in eclipse, given the way we typically run apps with things like the > > jetty-maven-plugin (the startup/shutdown pre/post integration test) > > > > Plus it prevents debugging the app server easily and doing the jdk 1.4 > > method hot swapping performed by eclipse. > > > > So I came up with a solution I believe is cleaner, works in and out of > > eclipse.... definitely open to suggestions for improvement, but I believe > > this will make devs a lot more productive, and I'd eventually like to see > > the community move away from the pre/post-integration test start/stop I > see > > us doing so often. > > > > Already using some of this at a couple of companies I've contracted in > the > > past. > > > > info is here: https://github.com/rexhoffman/test-extensions > > > > > > So here is the readme file from the project > > > > Pretty straight forward maven projects, build with > ehoffman-parent/pom.xml > > and a maven 3 install: > > > > End results: you'll be able to easily write tests that start up web > > applications in jetty (either by detecting a marking webapp.properties > > file in an open webapp project and running it exploded, or by scanning > > the target/ dir for .war files. > > > > The webapp is left open for all tests that happen to use it during the > > execution, whether driven by a right-click "run as" testng test in > > eclipse, or via maven surefire runner. > > > > There is equivalent support for Webdriver, where browser instances are > > pooled and tests are run multithreaded. > > > > So here is an example test: > > > > > > *package org.ehoffman.testing.module.webapp; > > > > import static > org.ehoffman.testing.fest.webdriver.WebElementAssert.assertThat; > > > > import org.ehoffman.testing.module.webdriver.WebDriverModule; > > import org.ehoffman.testng.extensions.Fixture; > > import org.ehoffman.testng.extensions.modules.FixtureContainer; > > import org.openqa.selenium.By; > > import org.openqa.selenium.WebDriver; > > import org.testng.annotations.Listeners; > > import org.testng.annotations.Test; > > > > @Listeners(MyEnforcer.class) > > public class SimpleTest { > > > > @Test(groups="functional") > > @Fixture(factory={EmbeddedWebappModule.class, > > WebDriverModule.Firefox.class, WebDriverModule.HtmlUnitIE6.class}) > > public void simpleTestOfApplication(){ > > WebDriver driver = FixtureContainer.getService(WebDriverModule.class); > > Application application = > > FixtureContainer.getService(EmbeddedWebappModule.class); > > driver.navigate().to(application.getDefaultRootUrl()); > > > > assertThat(driver.findElement(By.id("message"))).isDisplayed().textContains("the > > time is now : "); > > } > > }* > > > > So this test is actually run twice, once in Firefox, and once in > > HtmlUnit (because those modules both have a "getModuleType" method > > that returns the string "WebDriver") after starting up the app handled > > by EmbeddedWebappModule.class. > > > > Because these tests can be easily run and debugged in eclipse, method > > byte code replacement (stuff that's been around since jdk 1.4) can be > > used while debugging to work on methods either in the application or > > test (after popping it of the execution stack) > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > People develop abstractions by generalizing from concrete examples. > Every attempt to determine the correct abstraction on paper without > actually developing a running system is doomed to failure. No one > is that smart. A framework is a resuable design, so you develop it by > looking at the things it is supposed to be a design of. The more examples > you look at, the more general your framework will be. > > -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks > > > >
