On better testing for webapps in maven....
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)
Re: On better testing for webapps in maven....
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
Re: On better testing for webapps in maven....
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
