in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

Java Tools for Extreme programming mastering open source tools including - Hightower R.

Hightower R. Java Tools for Extreme programming mastering open source tools including - Wiley publishing , 2002. - 417 p.
ISBN: 0-471-20708
Download (direct link): javatoolsforextremeprog2002.pdf
Previous << 1 .. 89 90 91 92 93 94 < 95 > 96 97 98 99 100 101 .. 159 >> Next

private boolean isHtml(WebResponse response){ return response.getContentType().equals("text/html");
The isHtml() method checks to be sure that the response in which we are checking the links is in fact HTML (HttpUnit doesn't parse Flash content, for instance). After the available links in the response have been retrieved, checkAllLinks() iterates over the link array and attempts to put the text of each link into the checkedLinks set. If it is successful (indicating a new link), then checkAllLinks() attempts to verify the link with checkLink():
private void checkLink(WebLink link) throws Exception{
WebRequest request = link.getRequest(); url = request.getURL();
System.out.println("checking link: " + url);
String linkHost = url.getHost(); if(linkHost.equals({
WebResponse response = conversation.getResponse(request); this.checkAllLinks(response);
The is retrieved from the link through getRequest().getURL() (shown in expanded form). If the host part of the URL matches the host under test, then checkLink() retrieves the response (here is where an exception would be thrown) and then attempts checkAllLinks() in it. Finally, all of the links will be checked and the test will terminate.
At this point, the spider is perfectly usable. However, it has one major flaw: All the testing is carried out in one test method. That means that if one link fails, the entire test fails. This approach does not granularize the test output—if .1 percent of product pages (10 of 10,000) in a hypothetical catalog test suffer from a rare bug because of bad data in the database, we don't want the whole test to fail. We want to record the error, but have the test results reflect that 99.9 percent of the site is working.
Spider Development: Second Iteration
Because the spider is a testing class, our benchmark for the newly added functionality is that given the same input as our first iteration, it should yield the same results. With that quick and dirty test in mind, we begin integrating the HttpUnit spider into JUnit's framework. The integration shouldn't affect the core logic of the spider; it will still use a Set to keep track of already spidered links, ignore links outside a specified host, and so on. However, the test we ran as a method will be refactored into a separate object. The setup for the test (which we ran in testEntireSite) now exists in a separate class:
public class SpiderSiteTest {
public static Test suite(){
String host = "";
TestSuite suite = new TestSuite();
WebRequest homePage = new GetMethodWebRequest("http://" + host);
SpiderPageTest test =
new SpiderPageTest(homePage, new HashSet(), host); suite.addTest(test); return suite;
public static void main(String[] args){
new String[]{"xptoolkit.httpUnitSpiderSiteTest"}
The class declares a static suite method, which allows it to be accessed by JUnit's test runners as demonstrated in the main() method. The suite consists of a single instance of SpiderPageTest—the object that performs all the logic of spidering pages, checking results, and so on. SpiderSiteTest merely serves as a convenient test launcher. It could be replaced with a more sophisticated launcher class that, say, read in the host initial page from a properties file or some such.
The SpiderPageTest object is the critical piece of the testing application. Its public interface consists of two constructors that parameterize the behavior of the test as well as the methods specified in junit.framework.Test (see Chapter 14, "JUnit API Reference," for details). The constructors specify the WebRequest (or, for convenience, the WebLink from which the request is derived), a java.util.Set of links that have already been tested, and the host of the site to test (offsite links are ignored).
The Test interface specifies two methods: run(junit.framework.TestResult result) and countTestCases(). run() is supposed to execute the Test and report the outcome to the TestResult. We will cover this method in a moment. countTestCases() returns the total number of TestCases run by this Test. In this case, we have to
cheat and return 1, because we have no way of knowing in advance how many pages will be tested and, hence, how many tests will run. This clues us in to imperfect integration with JUnit. JUnit's designers expected TestCases to be the objects that actually execute a test (as opposed to aggregate or modify tests). Perhaps SpiderPageTest should be a TestCase. We write this down on our task list as something to investigate after our SpiderSiteTest runs. Once we have all the logic, we may be able to see how to reshape SpiderPageTest for better integration. See Listing 9.4 for the constructors and class initialization.
Listing 9.4: Constructors and Initialization for SpiderPageTest.
private WebConversation conversation = new WebConversation();
Previous << 1 .. 89 90 91 92 93 94 < 95 > 96 97 98 99 100 101 .. 159 >> Next