Interesting. I like this approach, but I think it's also useful to directly test the
code by using mock objects. In my Struts-EL tests, I did a little more than what was
in the existing base tests. I ended up setting header parameters for required
attribute values, and I read the headers on the "other end", and used JTidy to help
verify that I got required attribute values, and attribute values had the values I
expected. The drawback to having the mock object tests for Struts-EL (as opposed to
using your "complete jsp" test) is that I have to remember to call the "setFooExpr()"
setters, as opposed to the "setFoo()" setters (from the base class). I definitely like
the JSP approach, as that tests the TLD also, which the mock objects cannot test.
-----Original Message-----
From: James Mitchell [mailto:[EMAIL PROTECTED]]
Sent: Wed 02/12/2003 9:22 AM
To: Struts Developers
Cc:
Subject: New Tests
Lately, I've been focusing on building tests that cover the entire core
struts taglibs. I've completed logic and I'm now hacking away on the bean
tags.
I don't claim to be expert with Cactus, but there seem to be 2 different
approaches with respect to testing taglibs. (There are probably more, but
these 2 really seem to stick out in my mind)
The existing logic tags use the first approach which is programmatically
mimicing what the container will do wrt life cycle calls, the testing the
output or (in the case of boolean results) tag.condition(0, 0).
The second approach is to actually use a jsp to test the tag (this seems
more natural to me, and tests more peices of the puzzle IMHO). But this
comes at the cost of time for page compilation. Personnally, I can live
with that cost, for the benefits of using the real thing. Doing it this way
also covers a long time bullet item that I've been wanting to complete for a
quite some time. (Complete examples of every tag, with every conceivable
configuration)
For example:
When building the tests for the o.a.s.t.b.TestCookieTag, a typical test
looks like this:
...
...
//============================================================
public void beginCookieName(WebRequest testRequest) {
testRequest.addCookie(COOKIE_KEY, COOKIE_VAL);
}
public void testCookieName()
throws ServletException, JspException, IOException {
CookieTag tag = new CookieTag();
tag.setPageContext(pageContext);
tag.setName(COOKIE_KEY);
tag.setId("theId");
tag.doStartTag();
Cookie cookie = (Cookie)pageContext.getAttribute("theId");
assertEquals("Verify that the cookie was defined properly as a
scripting variable",
COOKIE_VAL,
cookie.getValue());
I rewrote this test to call a jsp instead:
//====================================================
public void beginCookieName(WebRequest webRequest) {
webRequest.addCookie(COOKIE_KEY, COOKIE_VAL);
webRequest.addParameter("cacheId", "1");
}
public void testCookieName()
throws ServletException, JspException, IOException {
request.setAttribute("runTest", "testCookieName");
pageContext.forward("/test/org/apache/struts/taglib/bean/TestCookieTag.jsp")
;
}
then in the jsp, I do this:
-----------------------------------------------------------------
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ page import="junit.framework.Assert"%>
<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
<bean:define id="COOKIE_KEY"
value="org.apache.struts.taglib.bean.COOKIE_KEY"/>
<bean:define id="COOKIE_VAL" value="Testing"/>
<logic:equal name="runTest" value="testCookieName">
<bean:cookie id="cookie" name="org.apache.struts.taglib.bean.COOKIE_KEY"/>
<bean:define id="cookieId" name="cookie" property="value"/>
<% Assert.assertEquals(COOKIE_VAL, cookieId); %>
</logic:equal>
I wanted to know if any of you have a preference to how we do this.
Comments?
--
James Mitchell
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
