October 2007 - portal-commits - Jboss List Archives

JBoss Portal SVN: r8718 - docs/template/user-guide/en.

by portal-commits＠lists.jboss.org

Author: julien(a)jboss.com Date: 2007-10-19 11:42:38 -0400 (Fri, 19 Oct 2007) New Revision: 8718 Removed: docs/template/user-guide/en/ajax.xml Log: remove obsolete file Deleted: docs/template/user-guide/en/ajax.xml =================================================================== --- docs/template/user-guide/en/ajax.xml 2007-10-19 13:41:53 UTC (rev 8717) +++ docs/template/user-guide/en/ajax.xml 2007-10-19 15:42:38 UTC (rev 8718) @@ -1,273 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<chapter id="ajax"> - <chapterinfo> - <author> - <firstname>Julien</firstname> - <surname>Viet</surname> - <email>julien.viet(a)jboss.com</email> - </author> - </chapterinfo> - <title>Ajax</title> - <para>This section covers the ajax features provided by the portal.</para> - <sect1> - <title>Introduction</title> - <para>Todo</para> - </sect1> - <sect1> - <title>Ajaxified markup</title> - <sect2> - <title>Ajaxified layouts</title> - <para>Part of the Ajax capabilities are implemented in the layout framework which provide the structure for - generating portal pages. The good news is that the existing layout only requires a few modifications in - order to be ajaxified.</para> - <para>We will use as example an simplified version of the layout JSP provided in JBoss Portal 2.6 and outline - what are the required changes that makes it an ajaxified layout: - <programlisting><![CDATA[ -<%@ taglib uri="/WEB-INF/theme/portal-layout.tld" prefix="p" %> -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" -"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml"> -<head> - <meta http-equiv="Content-Type" content="text/html;"/> -  - <p:theme themeName="renaissance"/> -  - <p:headerContent/> -</head> - -<body id="body"> -<p:region regionName='AJAXScripts' regionID='AJAXScripts'/> -<div id="portal-container"> - <div id="sizer"> - <div id="expander"> - <div id="logoName"></div> - <table border="0" cellpadding="0" cellspacing="0" id="header-container"> - <tr> - <td align="center" valign="top" id="header"> - -  - <p:region regionName='dashboardnav' regionID='dashboardnav'/> - -  - <p:region regionName='navigation' regionID='navigation'/> - <div id="spacer"></div> - </td> - </tr> - </table> - <div id="content-container"> -  - <p:region regionName='left' regionID='regionA'/> -  - <p:region regionName='center' regionID='regionB'/> - <hr class="cleaner"/> - </div> - </div> - </div> -</div> - -<p:region regionName='AJAXFooter' regionID='AJAXFooter'/> - -</body> -</html> -]]></programlisting> - <itemizedlist> - <listitem><![CDATA[<p:theme themeName="renaissance"/>]]> should be already present as it exists since 2.4 but is even more - necessary as it will inject in the page the reference to the ajax stylesheet.</listitem> - <listitem><![CDATA[<p:region regionName='AJAXScripts' regionID='AJAXScripts'/>]]> should be added before any other region - in the markup of the layout.</listitem> - <listitem><![CDATA[<p:region regionName='AJAXFooter' regionID='AJAXFooter'/>]]> should be added after any other region - in the markup of the layout.</listitem> - </itemizedlist> - </para> - </sect2> - <sect2> - <title>Ajaxified renderers</title> - <para>At runtime the portal combines the layout and the renderers in order create the markup returned to the - web browser. The most used render set is the divRenderer. Renderers only need a modification in the deployment - descriptor to indicate that they support ajax. Here is the declaration of the default divRenderer now in 2.6:</para> - <programlisting><![CDATA[ -<renderSet name="divRenderer"> - <set content-type="text/html"> - <ajax-enabled>true</ajax-enabled> - <region-renderer>org.jboss.portal.theme.impl.render.div.DivRegionRenderer - </region-renderer> - <window-renderer>org.jboss.portal.theme.impl.render.div.DivWindowRenderer - </window-renderer> - <portlet-renderer>org.jboss.portal.theme.impl.render.div.DivPortletRenderer - </portlet-renderer> - <decoration-renderer>org.jboss.portal.theme.impl.render.div.DivDecorationRenderer - </decoration-renderer> - </set> -</renderSet> -]]></programlisting> - <para>You should notice the <![CDATA[<ajax-enabled>true</ajax-enabled>]]> which indicates that the render set - supports ajaxification.</para> - </sect2> - </sect1> - <sect1> - <title>Ajaxified pages</title> - <para>The ajaxification of the portal pages can be configured in a fine grained manner. Thanks to the portal - object properties it is possible to control which pages support ajax and which page do not support ajax. The - administrator must pay attention to the fact that property values are inherited in the object hierarchy.</para> - <sect2> - <title>Drag and Drop</title> - <para>That feature is only effective in dashboards as it requires the offer personalization of the page - layout per user. By default the feature is enabled thanks to a property set on the dashboard object. - It is possible to turn off that property if the administrator does not want to expose that feature - to its user.</para> - <para>In the file <emphasis>jboss-portal.sar/conf/data/default-object.xml</emphasis> is declared and configured the - creation of the dashboard portal:</para> - <programlisting><![CDATA[ -<deployment> - <parent-ref/> - <if-exists>keep</if-exists> - <context> - <context-name>dashboard</context-name> - <properties> - ... - <property> - <name>theme.dyna.dnd_enabled</name> - <value>true</value> - </property> - ... - </properties> - ... - </context> -</deployment> -]]></programlisting> - <para>The property <emphasis>theme.dyna.dnd_enabled</emphasis> is set to the value <emphasis>true</emphasis> - which means that the dashboard object will provide the drag and drop feature. - </para> - </sect2> - <sect2> - <title>Partial refresh</title> - <para>Partial refresh is a very powerful feature which allows the portal to optimize the refreshing - of portlets on a page. When one portlet is invoked, instead of redrawing the full page, the portal is able - to detect which portlets needs to be refreshed and will update only these portlets.</para> - <mediaobject> - <imageobject> - <imagedata align="center" fileref="images/ajax/partial-refresh.png" format="png"/> - </imageobject> - <caption> - <para>The portal providing partial refresh</para> - </caption> - </mediaobject> - <sect3> - <title>Portal objects configuration</title> - <para>Like with the drag and drop feature, partial page refresh is controlled via properties on portal objects. - The name of the property is <emphasis>theme.dyna.partial_refresh_enabled</emphasis> and its values can - be <emphasis>true</emphasis> or <emphasis>false</emphasis>. When this property is set on an object - it is automatically inherited by the sub hierarchy located under that object. By default the drag - and drop feature is positionned on the dashboard object and not on the rest of the portal objects. - </para> - <programlisting><![CDATA[ -<deployment> - <parent-ref/> - <if-exists>keep</if-exists> - <context> - <context-name>dashboard</context-name> - <properties> - ... - <property> - <name>theme.dyna.partial_refresh_enabled</name> - <value>true</value> - </property> - ... - </properties> - ... - </context> -</deployment> -]]></programlisting> - <note> - The partial page refresh feature is compatible with the Portal API. The Portal API allows programmatic - update of the state of portlets at runtime. For instance it is possible to modify the window state or - the mode of several portlets on a given page. When such event occurs, the portal detects the changes - which occured and will update the portlet fragments in the page. - </note> - <para>It is possible to change that behavior at runtime using the property editor of the management portlet. - If you want to enable partial refreshing on the default portal you should set the property to true - directly on the portal and all the pages in that portal will automatically inherit those properties.</para> - <mediaobject> - <imageobject> - <imagedata align="center" fileref="images/ajax/partial-refresh-admin.png" format="png"/> - </imageobject> - <caption> - <para>The default portal configured for partial page refresh</para> - </caption> - </mediaobject> - </sect3> - <sect3> - <title>Portlet configuration</title> - <para> - By default any portlet will support partial refreshing. When does the portal performs partial page - refreshing ? By default it is enabled for action and render links with the following exceptions. In those - situations, the portal will prefer to perform a full page refresh: - <itemizedlist> - <listitem> - <para>Form GET are not handled, however it should not be an issue as this situation is discouraged - by the Portlet specification. It however taken in account, just in case of. Here is an example - of a Java Server Page that would do one:</para> - <programlisting><![CDATA[ -<form action="<%= renderResponse.createActionURL() %>" method="get"> - ... -</form> -]]></programlisting> - </listitem> - <listitem> - <para>Form uploads are not handled.</para> - </listitem> - <listitem>Having an interaction that deals with the <emphasis>MAXIMIZED</emphasis> window state. - When a window is entering a maximized state or leaving a maximized window state, the portal will - perform a full page refresh.</listitem> - </itemizedlist> - </para> - <para>It can happen that a portlet does not want to support partial refreshing, in those situations - the <emphasis>jboss-portlet.xml</emphasis> can be used to control that behavior. Since 2.6 an ajax - section has been added in order to configure ajax features related to the portlet.</para> - <programlisting><![CDATA[ -<portlet> - <portlet-name>MyPortletNoAjax</portlet-name> - <ajax> - <partial-refresh>false</partial-refresh> - </ajax> -</portlet> -]]></programlisting> - <para>The usage of the <emphasis>partial-refresh</emphasis> set to the value false means that - the portlet will not be subject of a partial page refresh when it is invoked. However the portlet - markup can still be subject to a partial rendering.</para> - </sect3> - <sect3> - <title>Limitations</title> - <para>Partial refreshing of portlets has limitations both on the server side (portal) and on the client side (browser).</para> - <sect4> - <title>Application scoped session attributes</title> - <para>When partial refresh is activated, the state of a page can potentially become inconsistent. for - example, if some objects are shared in the application scope of the session between portlets. When one - portlet update a session object, the other portlet won't be refreshed and will still display content based - on the previous value of the object in the session. To avoid that, partial refresh can be desactivated - for certain portlets by adding <portlet-refresh>false<portlet-refresh> in the jboss-portlet.xml file.</para> - </sect4> - <sect4> - <title>Non ajax interactions</title> - <para>The solution developped by JBoss Portal on the client side is built on top of DOM events emitted - by the web browser when the user interracts with the page. If an interaction is done without an - emission of an event then JBoss Portal will not be able to transform it into a partial refresh and - it will result instead of a full refresh. This can happen with programmatic submission of forms. - </para> - <programlisting><![CDATA[ -<form id="<%= formId %>" action="<%= renderResponse.createActionURL() %>" method="post"> - ... - <select onclick="document.getElementById('<%= formId %>').submit()"> - ... - </select> - ... -</form> -]]></programlisting> - </sect4> - </sect3> - </sect2> - </sect1> -</chapter> \ No newline at end of file

16 years, 7 months

1
0
0 / 0

JBoss Portal SVN: r8717 - in branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core: impl/model/content/generic and 3 other directories.

by portal-commits＠lists.jboss.org

Author: thomas.heute(a)jboss.com Date: 2007-10-19 09:41:53 -0400 (Fri, 19 Oct 2007) New Revision: 8717 Modified: branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/impl/model/content/InternalContentProvider.java branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/impl/model/content/generic/InternalGenericContentProvider.java branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/impl/model/portal/WindowImpl.java branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/model/portal/Window.java branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/model/portal/navstate/WindowNavigationalState.java Log: JBPORTAL-1300: Ability to define an initial window state and mode Modified: branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/impl/model/content/InternalContentProvider.java =================================================================== --- branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/impl/model/content/InternalContentProvider.java 2007-10-19 12:47:43 UTC (rev 8716) +++ branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/impl/model/content/InternalContentProvider.java 2007-10-19 13:41:53 UTC (rev 8717) @@ -22,30 +22,35 @@ ******************************************************************************/ package org.jboss.portal.core.impl.model.content; +import java.util.ArrayList; +import java.util.Collections; +import java.util.HashMap; +import java.util.Iterator; +import java.util.List; +import java.util.Map; +import java.util.Set; + import org.jboss.logging.Logger; import org.jboss.portal.Mode; import org.jboss.portal.WindowState; -import org.jboss.portal.security.spi.auth.PortalAuthorizationManager; -import org.jboss.portal.security.spi.auth.PortalAuthorizationManagerFactory; import org.jboss.portal.core.aspects.portlet.AjaxInterceptor; import org.jboss.portal.core.controller.ControllerContext; import org.jboss.portal.core.controller.ControllerResponse; -import org.jboss.portal.core.controller.command.response.UnavailableResourceResponse; import org.jboss.portal.core.controller.command.response.SecurityErrorResponse; +import org.jboss.portal.core.controller.command.response.UnavailableResourceResponse; import org.jboss.portal.core.controller.portlet.PortletInvocationFactory; import org.jboss.portal.core.model.content.Content; import org.jboss.portal.core.model.content.ContentType; import org.jboss.portal.core.model.content.spi.ContentProvider; import org.jboss.portal.core.model.instance.Instance; -import org.jboss.portal.core.model.instance.InstanceCustomization; import org.jboss.portal.core.model.instance.InstancePermission; import org.jboss.portal.core.model.portal.Portal; import org.jboss.portal.core.model.portal.PortalObjectId; import org.jboss.portal.core.model.portal.Window; -import org.jboss.portal.core.model.portal.content.WindowRendition; -import org.jboss.portal.core.model.portal.command.response.MarkupResponse; import org.jboss.portal.core.model.portal.command.render.RenderWindowCommand; +import org.jboss.portal.core.model.portal.command.response.MarkupResponse; import org.jboss.portal.core.model.portal.content.ContentRenderer; +import org.jboss.portal.core.model.portal.content.WindowRendition; import org.jboss.portal.core.model.portal.navstate.WindowNavigationalState; import org.jboss.portal.core.navstate.NavigationalStateKey; import org.jboss.portal.portlet.NoSuchPortletException; @@ -58,19 +63,13 @@ import org.jboss.portal.portlet.invocation.response.ErrorResponse; import org.jboss.portal.portlet.invocation.response.FragmentResponse; import org.jboss.portal.portlet.invocation.response.InsufficientPrivilegesResponse; +import org.jboss.portal.portlet.invocation.response.InsufficientTransportGuaranteeResponse; import org.jboss.portal.portlet.invocation.response.PortletInvocationResponse; import org.jboss.portal.portlet.invocation.response.UnavailableResponse; -import org.jboss.portal.portlet.invocation.response.InsufficientTransportGuaranteeResponse; +import org.jboss.portal.security.spi.auth.PortalAuthorizationManager; +import org.jboss.portal.security.spi.auth.PortalAuthorizationManagerFactory; import org.jboss.portal.theme.impl.render.dynamic.DynaRenderOptions; -import java.util.ArrayList; -import java.util.HashMap; -import java.util.Iterator; -import java.util.List; -import java.util.Map; -import java.util.Collections; -import java.util.Set; - /** * @author <a href="mailto:julien@jboss.org">Julien Viet</a> * @version $Revision: 1.1 $ @@ -173,7 +172,7 @@ // if (windowNS == null) { - windowNS = new WindowNavigationalState(WindowState.NORMAL, Mode.VIEW, null); + windowNS = new WindowNavigationalState(window.getInitialWindowState(), window.getInitialMode(), null); context.setAttribute(RenderWindowCommand.NAVIGATIONAL_STATE_SCOPE, nsKey, windowNS); } Modified: branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/impl/model/content/generic/InternalGenericContentProvider.java =================================================================== --- branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/impl/model/content/generic/InternalGenericContentProvider.java 2007-10-19 12:47:43 UTC (rev 8716) +++ branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/impl/model/content/generic/InternalGenericContentProvider.java 2007-10-19 13:41:53 UTC (rev 8717) @@ -203,7 +203,7 @@ state.setValue("uri", uri); // - WindowNavigationalState.setState(nsResolver, nsKey, state); + WindowNavigationalState.setState(nsResolver, nsKey, state, window); } // Modified: branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/impl/model/portal/WindowImpl.java =================================================================== --- branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/impl/model/portal/WindowImpl.java 2007-10-19 12:47:43 UTC (rev 8716) +++ branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/impl/model/portal/WindowImpl.java 2007-10-19 13:41:53 UTC (rev 8717) @@ -22,6 +22,8 @@ ******************************************************************************/ package org.jboss.portal.core.impl.model.portal; +import org.jboss.portal.Mode; +import org.jboss.portal.WindowState; import org.jboss.portal.core.model.portal.PortalObject; import org.jboss.portal.core.model.portal.Window; import org.jboss.portal.core.model.portal.Page; @@ -43,6 +45,10 @@ public static final String PORTAL_PROP_WINDOW_CONTENT_TYPE = "portal.windowContentType"; + public static final String PORTAL_INITIAL_WINDOW_STATE = "portal.windowInitialState"; + + public static final String PORTAL_INITIAL_MODE = "portal.windowInitialMode"; + // Persistent state protected String uri; @@ -274,4 +280,30 @@ } } } + + public WindowState getInitialWindowState() + { + String value = getDeclaredProperty(PORTAL_INITIAL_WINDOW_STATE); + if (value != null) + { + return WindowState.create(value); + } + else + { + return WindowState.NORMAL; + } + } + + public Mode getInitialMode() + { + String value = getDeclaredProperty(PORTAL_INITIAL_MODE); + if (value != null) + { + return Mode.create(value); + } + else + { + return Mode.VIEW; + } + } } Modified: branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/model/portal/Window.java =================================================================== --- branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/model/portal/Window.java 2007-10-19 12:47:43 UTC (rev 8716) +++ branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/model/portal/Window.java 2007-10-19 13:41:53 UTC (rev 8717) @@ -22,6 +22,8 @@ ******************************************************************************/ package org.jboss.portal.core.model.portal; +import org.jboss.portal.Mode; +import org.jboss.portal.WindowState; import org.jboss.portal.core.model.content.Content; import org.jboss.portal.core.model.content.ContentType; @@ -55,4 +57,20 @@ * @return the window content */ Content getContent(); + + /** + * Returns the inital window state (the window state to use when no navigational + * state exists, for example on a new page request) for this particular window + * + * @return a windowState + */ + WindowState getInitialWindowState(); + + /** + * Returns the inital mode to use (the mode to use when no navigational + * state exists, for example on a new page request) for this particular window + * + * @return a portlet mode + */ + Mode getInitialMode(); } Modified: branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/model/portal/navstate/WindowNavigationalState.java =================================================================== --- branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/model/portal/navstate/WindowNavigationalState.java 2007-10-19 12:47:43 UTC (rev 8716) +++ branches/JBoss_Portal_Branch_2_6/core/src/main/org/jboss/portal/core/model/portal/navstate/WindowNavigationalState.java 2007-10-19 13:41:53 UTC (rev 8717) @@ -25,6 +25,7 @@ import org.jboss.portal.WindowState; import org.jboss.portal.Mode; import org.jboss.portal.common.invocation.AttributeResolver; +import org.jboss.portal.core.model.portal.Window; import org.jboss.portal.core.navstate.NavigationalStateKey; import org.jboss.portal.portlet.StateString; @@ -233,6 +234,42 @@ resolver.setAttribute(key, wns); } + public static void setState(AttributeResolver resolver, NavigationalStateKey key, StateString state, Window window) + { + if (resolver == null) + { + throw new IllegalArgumentException("No null resolver"); + } + if (key == null) + { + throw new IllegalArgumentException("No null key"); + } + if (state == null) + { + throw new IllegalArgumentException("No null state"); + } + if (window == null) + { + throw new IllegalArgumentException("No null window"); + } + + // + WindowNavigationalState wns = (WindowNavigationalState)resolver.getAttribute(key); + + // + if (wns == null) + { + wns = new WindowNavigationalState(window.getInitialWindowState(), window.getInitialMode(), state); + } + else + { + wns = new WindowNavigationalState(wns.getWindowState(), wns.getMode(), state); + } + + // + resolver.setAttribute(key, wns); + } + public static WindowNavigationalState bilto(WindowNavigationalState oldNS, WindowState windowState, Mode mode, StateString contentState) { StateString newState = oldNS != null ? oldNS.getContentState() : null;

16 years, 7 months

1
0
0 / 0

JBoss Portal SVN: r8716 - modules/test/trunk/docs/user-guide/en/modules.

by portal-commits＠lists.jboss.org

Author: julien(a)jboss.com Date: 2007-10-19 08:47:43 -0400 (Fri, 19 Oct 2007) New Revision: 8716 Modified: modules/test/trunk/docs/user-guide/en/modules/introduction.xml Log: more documentation Modified: modules/test/trunk/docs/user-guide/en/modules/introduction.xml =================================================================== --- modules/test/trunk/docs/user-guide/en/modules/introduction.xml 2007-10-19 12:28:58 UTC (rev 8715) +++ modules/test/trunk/docs/user-guide/en/modules/introduction.xml 2007-10-19 12:47:43 UTC (rev 8716) @@ -10,7 +10,23 @@ <title>Introduction</title> <sect1> <title>Motivation</title> - <para>Todo</para> + <para>The JBoss Portal project historically has used JUnit as test framework. With the evolution of the project + its testing became more and more complex and required the development of several utility classes interacting + with JUnit. Those utilities became more complex and at some point the integration with JUnit required to + introduce hacks in order to get the testsuite of the project to execute.</para> + <para>When we decided to migrate the codebase to Java 5, the TestNG framework had emerged for a couple of years + and I hoped it would be the silver bullet that would solve my problems. After its study, I realized + that it was below my expectations in terms of integration.</para> + <para>Most of the existing unit test framework assumes that we test only Java objects which leads to frameworks + that expose object related idioms in their interface. A large part of the portal tests cannot be considered + as just Java objects and it would have been very difficult to integrate those tests with the existing frameworks.</para> + <para>Of course before I started this effort I tried to gather the pros and the cons of such an effort. The major + cons is about to not reinvent the wheel or that I should not spend my time developping something that not only + already exists but will require maintenance!!! A few things convinced me that I was right. The fact that the current + wheels don't meet my expectations and I spent much more time in the past to integrate JUnit with JBoss Portal codebase + rather than developping JBoss Unit. The fact that after all it is just a test framework and does not require much + maintenance, indeed JUnit was claimed to be invented in a few hours!!! Probably also the fact that it is just + a good thing to invest time in a tool that will make me save more time in the future.</para> </sect1> <sect1> <title>Principles</title>

16 years, 7 months

1
0
0 / 0

JBoss Portal SVN: r8715 - in modules/test/trunk: unit/src/main/org/jboss/unit/api/pojo/annotations and 1 other directories.

by portal-commits＠lists.jboss.org

Author: julien(a)jboss.com Date: 2007-10-19 08:28:58 -0400 (Fri, 19 Oct 2007) New Revision: 8715 Modified: modules/test/trunk/docs/user-guide/en/modules/pojotesting.xml modules/test/trunk/unit/src/main/org/jboss/unit/api/pojo/annotations/Description.java modules/test/trunk/unit/src/main/org/jboss/unit/spi/pojo/TestProviderSupport.java Log: more documentation Modified: modules/test/trunk/docs/user-guide/en/modules/pojotesting.xml =================================================================== --- modules/test/trunk/docs/user-guide/en/modules/pojotesting.xml 2007-10-19 10:42:51 UTC (rev 8714) +++ modules/test/trunk/docs/user-guide/en/modules/pojotesting.xml 2007-10-19 12:28:58 UTC (rev 8715) @@ -413,18 +413,237 @@ <sect2> <title><interfacename>@Description</interfacename></title> - <para></para> + <para>The <interfacename>@Description</interfacename> annotation can be used to annotate a test class, a test + case of a test parameter and provide a description</para> + + <example> + <programlisting><![CDATA[ +import org.jboss.unit.api.pojo.annotations.Parameter; +import org.jboss.unit.api.pojo.annotations.Description; +import org.jboss.unit.api.pojo.annotations.Test; + +@Description("A test suite") +public class MyTest +{ + + private String foo; + + @Parameter + @Description("A test parameter") + public void setFoo(String foo) + { + this.foo = foo; + } + + @Test + @Description("A test case") + public void test() + { + } +} +]]></programlisting> + <caption> + <para>A test described</para> + </caption> + </example> + </sect2> <sect2> <title><interfacename>@Tag</interfacename></title> - <para></para> + <para>The <interfacename>@Tag</interfacename> annotation allow to tag a tested item with keywords. The main usage + of keywords is at runtime in order to provide filtering of tests. It is very useful whenever you just want + to execute a subset of the tests based on a set of keywords.</para> + + <example> + <programlisting><![CDATA[ +import org.jboss.unit.api.pojo.annotations.Keyword; +import org.jboss.unit.api.pojo.annotations.Test; + +@Tag({"foo", "bar"}) +public class MyTest +{ + @Test + @Tag({"foo"}) + public void test() + { + } +} +]]></programlisting> + <caption> + <para>A test annotated with keywords</para> + </caption> + </example> + </sect2> </sect1> <sect1> <title>Integration with JBoss Microcontainer</title> + + <para>The JBoss Microcontainer provides a lighweight container for managing POJOs, their deployment and + configuration. The integration within JBoss Unit provides a powerful way to setup complex assembly of + POJOs that will be part of unit tests.</para> + <para>This section will provide the general syntax and an example of usage, for further details concerning + JBoss Microcontainer you should look at its documentation.</para> + + <sect2> + <title>Triggering a microcontainer boostrap with the <interfacename>@Bootstrap</interfacename> annotation</title> + <para>The main usage of JBoss Microcontainer is done through the <interfacename>@Bootstrap</interfacename> annotation. + It has a <parameter>resourceName</parameter> parameter which indicates the resource name of the microcontainer + bootstrap file.</para> + <para>The current POJO being tested will be inserted in the microcontainer kernel and it is possible to reference it + in the bootstrap file under the special <literal>TestCase</literal> name. It is possible to override the name + using the <parameter>beanName</parameter> parameter of the <interfacename>@Bootstrap</interfacename> annotation. There + are several ways to leverage this: + <itemizedlist> + <listitem>Inject the test case in a bean</listitem> + <listitem>Inject a property of the test case in a bean such as a parameter of the test case</listitem> + <listitem>Inject a bean in the test case POJO using JBoss Microcontainer annotations</listitem> + </itemizedlist> + </para> + </sect2> + + <sect2> + <title>Example</title> + <para>In this example we will show how to create a parameterized test case that bootstrap a bean using + the microcontainer. The boostrapped bean will be configured from the test case parameters and then + will be injected in the test case.</para> + + <example> + <programlisting><![CDATA[ +public class MyService +{ + + private String dataSourceName; + + public String getDataSourceName() + { + return dataSourceName; + } + + public void setDataSourceName(String dataSourceName) + { + this.dataSourceName = dataSourceName; + } + + public void start() + { + System.out.println("MyService start for data source " + dataSourceName); + } + + public void stop() + { + System.out.println("MyService stop"); + } + +} +]]></programlisting> + <caption> + <para>The service</para> + </caption> + </example> + + <example> + <programlisting><![CDATA[ +@Bootstrap(resourceName ="/jboss-beans.xml") +public class MyTest +{ + + private MyService service; + private String dataSourceName; + + public MyService getService() + { + return service; + } + + @Inject(bean="Service") + public void setService(MyService service) + { + this.service = service; + } + + public String getDataSourceName() + { + return dataSourceName; + } + + @Parameter + + public void setDataSourceName(String dataSourceName) + { + this.dataSourceName = dataSourceName; + } + + @Test + public void test() + { + System.out.println("MyTest test with service " + service); + } +} +]]></programlisting> + <caption> + <para>The test suite</para> + </caption> + </example> + + <para>Our tested system is composed of a service and a test suite. The service is configured from + a <parameter>dataSourceName</parameter> parameter that will be injected from the test suite <parameter>dataSourceName</parameter> + corresponding property. The test suite is parameterized with the <parameter>dataSourceName</parameter> parameter that will + be set by JBoss Unit. The test suite interacts with the microcontainer thanks to the <interfacename>@Bootstrap</interfacename> + annotation configured to use the file available from the classpath under the name <literal>/jboss-beans.xml</literal>. The + <interfacename>@Inject</interfacename> annotation is a microcontainer annotation that will trigger the injection + of the service in the test case.</para> + + <example> + <programlisting><![CDATA[ +<?xml version="1.0" encoding="UTF-8"?> +<deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:jboss:bean-deployer:2.0 bean-deployer_2_0.xsd" + xmlns="urn:jboss:bean-deployer:2.0"> + + <bean name="Service" class="org.jboss.test.unit.mc.MyService"> + <property name="dataSourceName"><inject + bean="TestCase" + property="dataSourceName" + state="Instantiated"/></property> + </bean> + +</deployment> +]]></programlisting> + <caption> + <para>The <filename>jboss-beans.xml</filename> file</para> + </caption> + </example> + + <note>The injection of the <parameter>dataSourceName</parameter> property from the <literal>TestCase</literal> bean + requires to add the <parameter>state</parameter> attribute with the value <literal>Instantiated</literal>. Without + this we would have a a bidirectional dependency between the service and the test case and the kernel would not + be able to resolve it: the test case wants the injection of the service and the service wants the injection + of a portion of the test case state. Using the <literal>Instantiated</literal> state tells the kernel to use + the test case bean when it is instantiated and that allows the resolution of all the dependencies.</note> + + <para>One of the benefit of using JBoss Microcontainer is that it takes care of the overral orchestration of the whole setup + and resolve the dependencies and configuration issues. When JBoss Unit executes the test case the following sequence happens: + <itemizedlist> + <listitem>An instance of <classname>MyTest</classname> is created by JBoss Unit</listitem> + <listitem>JBoss Unit configures the instance and set the <parameter>dataSourceName</parameter> property</listitem> + <listitem>JBoss Unit creates a new microcontainer kernel and registers the <classname>MyTest</classname> instance under the <literal>TestCase</literal> name</listitem> + <listitem>JBoss Unit deploys the <filename>jboss-beans.xml</filename> file</listitem> + <listitem>JBoss MC creates an instance of the <classname>MyService</classname> service and configures it with the test case <parameter>dataSourceName</parameter> + value</listitem> + <listitem>JBoss MC starts the service</listitem> + <listitem>JBoss MC inject the service in the test case</listitem> + </itemizedlist> + </para> + + <para>Once the test is finished a shutdown of the kernel will be done that will trigger the stopping and destruction of the + involved services.</para> + + </sect2> + </sect1> </chapter> Modified: modules/test/trunk/unit/src/main/org/jboss/unit/api/pojo/annotations/Description.java =================================================================== --- modules/test/trunk/unit/src/main/org/jboss/unit/api/pojo/annotations/Description.java 2007-10-19 10:42:51 UTC (rev 8714) +++ modules/test/trunk/unit/src/main/org/jboss/unit/api/pojo/annotations/Description.java 2007-10-19 12:28:58 UTC (rev 8715) @@ -38,6 +38,6 @@ public @interface Description { - String description(); + String value(); } Modified: modules/test/trunk/unit/src/main/org/jboss/unit/spi/pojo/TestProviderSupport.java =================================================================== --- modules/test/trunk/unit/src/main/org/jboss/unit/spi/pojo/TestProviderSupport.java 2007-10-19 10:42:51 UTC (rev 8714) +++ modules/test/trunk/unit/src/main/org/jboss/unit/spi/pojo/TestProviderSupport.java 2007-10-19 12:28:58 UTC (rev 8715) @@ -118,7 +118,7 @@ // Description descriptionAnnotation = ((AnnotatedElement)testClass).getAnnotation(Description.class); - String suiteDescription = descriptionAnnotation != null ? descriptionAnnotation.description() : ""; + String suiteDescription = descriptionAnnotation != null ? descriptionAnnotation.value() : ""; if (suiteDescription.length() == 0) { suiteDescription = "Test of class " + testClass.getName(); @@ -226,7 +226,7 @@ // Description descriptionMethodAnnotation = method.getAnnotation(Description.class); - String description = descriptionMethodAnnotation != null ? descriptionMethodAnnotation.description() : ""; + String description = descriptionMethodAnnotation != null ? descriptionMethodAnnotation.value() : ""; if (description.length() == 0) { description = "Parameter " + name; @@ -361,7 +361,7 @@ // Description descriptionArgumentParameterAnnotation = (Description)parameterAnnotationMap.get(Description.class); - String description = descriptionArgumentParameterAnnotation != null ? descriptionArgumentParameterAnnotation.description() : ""; + String description = descriptionArgumentParameterAnnotation != null ? descriptionArgumentParameterAnnotation.value() : ""; if (description.length() == 0) { description = "Method parameter " + name; @@ -385,7 +385,7 @@ // Description descriptionMethodAnnotation = method.getAnnotation(Description.class); - String description = descriptionMethodAnnotation != null ? descriptionMethodAnnotation.description() : ""; + String description = descriptionMethodAnnotation != null ? descriptionMethodAnnotation.value() : ""; if (description.length() == 0) { description = "Test of method " + method.getName();

16 years, 7 months

1
0
0 / 0

JBoss Portal SVN: r8714 - modules/test/trunk/docs/user-guide/en/modules.

by portal-commits＠lists.jboss.org

Author: julien(a)jboss.com Date: 2007-10-19 06:42:51 -0400 (Fri, 19 Oct 2007) New Revision: 8714 Modified: modules/test/trunk/docs/user-guide/en/modules/pojotesting.xml Log: more documentation Modified: modules/test/trunk/docs/user-guide/en/modules/pojotesting.xml =================================================================== --- modules/test/trunk/docs/user-guide/en/modules/pojotesting.xml 2007-10-19 09:53:23 UTC (rev 8713) +++ modules/test/trunk/docs/user-guide/en/modules/pojotesting.xml 2007-10-19 10:42:51 UTC (rev 8714) @@ -96,7 +96,8 @@ <sect3> <title><methodname>assertNull</methodname></title> - <programlisting><![CDATA[ + <example> + <programlisting><![CDATA[ public class MyTest { @Test @@ -106,123 +107,324 @@ } } ]]></programlisting> - <para>Assert that the argument is null.</para> + <caption> + <para>Assert that the argument is <literal>null</literal>.</para> + </caption> + </example> </sect3> <sect3> <title><methodname>assertNotNull</methodname></title> - <programlisting><![CDATA[ + <example> + <programlisting><![CDATA[ public class MyTest { @Test public void test() { + assertNotNull("foo"); String s = assertNotNull("foo"); } } ]]></programlisting> - <para>Assert that the argument is not null. The method relies on the generics and returns the same type - of the argument type in order to avoid a type cast, improving the readability of the code.</para> + <caption> + <para>Assert that the argument is not <literal>null</literal>. The method relies on the generics and returns the same type + of the argument type in order to avoid a type cast, improving the readability of the code.</para> + </caption> + </example> </sect3> <sect3> - <title><methodname></methodname></title> - <programlisting><![CDATA[ + <title><methodname>assertEquals</methodname></title> + <example> + <programlisting><![CDATA[ public class MyTest { @Test public void test() { + assertEquals("foo", "foo"); + assertEquals(null, null); + assertEquals(1, 1); + assertEquals(true, true); + assertEquals(new String[]{"foo"}, new String[]{"foo"}); } } ]]></programlisting> - <para>.</para> + <caption> + <para>Assert that the arguments are either <literal>null</literal> or both are non <literal>null</literal> and the invocation of the first argument + <methodname>equals</methodname> method with the second argument as parameter returns true.</para> + </caption> + </example> </sect3> <sect3> - <title><methodname></methodname></title> - <programlisting><![CDATA[ + <title><methodname>assertNotEquals</methodname></title> + <example> + <programlisting><![CDATA[ public class MyTest { @Test public void test() { + assertNotEquals("foo", "bar"); + assertNotEquals("foo", null); + assertNotEquals(null, "bar"); + assertNotEquals(true, false); + assertNotEquals(1, 2); } } ]]></programlisting> - <para>.</para> + <caption> + <para>Assert that either one argument is <literal>null</literal> and the other is not or that both arguments are non + <literal>null</literal> and the invocation of the first argument <methodname>equals</methodname> method returns false.</para> + </caption> + </example> </sect3> <sect3> - <title><methodname></methodname></title> - <programlisting><![CDATA[ + <title><methodname>assertSame</methodname></title> + <example> + <programlisting><![CDATA[ public class MyTest { @Test public void test() { + Object o = new Object(); + assertSame(o, o); + assertSame(null, null); } } ]]></programlisting> - <para>.</para> + <caption> + <para>Assert that the arguments are either <literal>null</literal> or are non <literal>null</literal> and have the same reference.</para> + </caption> + </example> </sect3> <sect3> - <title><methodname></methodname></title> - <programlisting><![CDATA[ + <title><methodname>assertNotSame</methodname></title> + <example> + <programlisting><![CDATA[ public class MyTest { @Test public void test() { + assertNotSame(new String("foo"), "foo"); + assertNotSame("foo", null); + assertNotSame(null, "bar"); } } ]]></programlisting> - <para>.</para> + <caption> + <para>Assert that either one argument is <literal>null</literal> and the other is not or that both arguments + are non <literal>null</literal> but do not share the same reference.</para> + </caption> + </example> </sect3> <sect3> - <title><methodname></methodname></title> - <programlisting><![CDATA[ + <title><methodname>assertInstanceOf</methodname></title> + <example> + <programlisting><![CDATA[ public class MyTest { @Test public void test() { + assertInstanceOf(o, String.class); + String s = assertInstanceOf(o, String.class); } } ]]></programlisting> - <para>.</para> + <caption> + <para>Assert that an object implements or extends the specified class object. It leverages the generics to + have the same return type than the class argument which allow to reuse the object with its asserted class + directly.</para> + </caption> + </example> </sect3> + </sect2> + </sect1> - <sect3> - <title><methodname></methodname></title> + <sect1> + <title>Annotations</title> + <para>So far we have covered only the <interfacename>@Test</interfacename> annotation, in this chapter we will + review the other annotations available.</para> + + <sect2> + <title><interfacename>@Parameter</interfacename></title> + <para>It is often interesting to run several times the same test with different initial conditions. The + <interfacename>@Parameter</interfacename> annotation can be used to provide an initial state to the tests. + It is possible to annotate Javabean property setters or test case method arguments. When a property is annotated, + the parameter is scoped for all test cases contained in the POJO. Note that it is allowed to override + the name of the parameter using the <parameter>name</parameter> argument of the annotation.</para> + + <example> <programlisting><![CDATA[ +import org.jboss.unit.api.pojo.annotations.Test; +import org.jboss.unit.api.pojo.annotations.Parameter; +import static org.jboss.unit.api.Assert.*; + public class MyTest { + + private String foo; + private String juu; + + @Parameter + public void setFoo(String foo) + { + this.foo = foo; + } + + @Parameter(name = "bar") + public void setJuu(String juu) + { + this.juu = juu; + } + @Test public void test() { + assertEquals(foo, bar); } } ]]></programlisting> - <para>.</para> - </sect3> + <caption> + <para>A POJO with annotated Javabean property setters</para> + </caption> + </example> - <sect3> - <title><methodname></methodname></title> + <para>When a test case method argument is annotated, only the test case will have access to the parameter. In that + use case, the optional annotation parameter <parameter>name</parameter> becomes mandatory.</para> + + <example> <programlisting><![CDATA[ +import org.jboss.unit.api.pojo.annotations.Test; +import org.jboss.unit.api.pojo.annotations.Parameter; +import static org.jboss.unit.api.Assert.*; + public class MyTest { + + private String foo; + + @Parameter + public void setFoo(String foo) + { + this.foo = foo; + } + @Test + public void test(@Parameter(name = "bar") String bar) + { + assertEquals(foo, bar); + } +} +]]></programlisting> + <caption> + <para>A POJO with annotated Javabean property setters</para> + </caption> + </example> + + </sect2> + + <sect2> + <title><interfacename>@Test</interfacename></title> + <para>The <interfacename>@Test</interfacename> annotation is used to annotate a test case method that + is invoked at runtime by the JBoss Unit POJO extension. The method must be public, non static, non abstract + and should have only arguments annotated with an <interfacename>@Parameter</interfacename> annotation.</para> + + <para>By default the test name is the name of the + method but the annotation can be parameterized with a <parameter>name</parameter> argument that + will override the default name.</para> + + <example> + <programlisting><![CDATA[ +import org.jboss.unit.api.pojo.annotations.Test; + +public class MyTest +{ + + @Test public void test() { } + + @Test(name = "test2") + public void test1() + { + } + + @Test + public void test(@Parameter(name = "bar") String bar) + { + } } ]]></programlisting> - <para>.</para> - </sect3> + <caption> + <para>A POJO with several test cases</para> + </caption> + </example> </sect2> + + <sect2> + <title><interfacename>@Create</interfacename> and <interfacename>@Destroy</interfacename></title> + <para>The <interfacename>@Create</interfacename> and <interfacename>@Destroy</interfacename> annotations + are targetted for public, non static, methods that will be invoked to provide the POJO notifications + of the test life cycle.</para> + <para>The create method will be invoked prior any test case and will have access to POJO scoped parameters. + It is allowed to fail by throwing any kind of throwable and will make the test fail whenever it happens. If the + create method fails the test case method will not be invoked.</para> + <para>The destroy method is guaranteed to be always invoked whether the test pass or fails.</para> + <example> + <programlisting><![CDATA[ +import org.jboss.unit.api.pojo.annotations.Create; +import org.jboss.unit.api.pojo.annotations.Destroy; +import org.jboss.unit.api.pojo.annotations.Test; + +public class MyTest +{ + @Create + public void create() + { + } + + @Test + public void test() + { + } + + @Destroy + public void destroy() + { + } +} +]]></programlisting> + <caption> + <para>A POJO aware of its life cycle</para> + </caption> + </example> + </sect2> + + <sect2> + <title><interfacename>@Description</interfacename></title> + <para></para> + </sect2> + + <sect2> + <title><interfacename>@Tag</interfacename></title> + <para></para> + </sect2> + </sect1> + + <sect1> + <title>Integration with JBoss Microcontainer</title> + </sect1> + </chapter>

16 years, 7 months

1
0
0 / 0

JBoss Portal SVN: r8713 - modules/test/trunk/unit/src/main/org/jboss/test/unit/api.

by portal-commits＠lists.jboss.org

Author: julien(a)jboss.com Date: 2007-10-19 05:53:23 -0400 (Fri, 19 Oct 2007) New Revision: 8713 Modified: modules/test/trunk/unit/src/main/org/jboss/test/unit/api/AssertTests.java Log: added tests cases for equals/notequals for integer and boolean Modified: modules/test/trunk/unit/src/main/org/jboss/test/unit/api/AssertTests.java =================================================================== --- modules/test/trunk/unit/src/main/org/jboss/test/unit/api/AssertTests.java 2007-10-19 09:01:48 UTC (rev 8712) +++ modules/test/trunk/unit/src/main/org/jboss/test/unit/api/AssertTests.java 2007-10-19 09:53:23 UTC (rev 8713) @@ -45,12 +45,72 @@ testObjectNotSame(); testFail(); testInstanceOf(); + testInteger(); + testBoolean(); } - public static void testInstanceOf() + private static void testBoolean() { + testAssertEquals(true, true); + testAssertEquals(true, new Boolean(true)); + testAssertEquals(new Boolean(true), new Boolean(true)); + testAssertEquals(new Boolean(true), true); + testAssertNotEquals(true, false); + testAssertNotEquals(new Boolean(true), false); + testAssertNotEquals(true, new Boolean(false)); + testAssertNotEquals(true, new Boolean(false)); + testAssertNotEquals(true, null); + testAssertNotEquals(new Boolean(true), null); + testAssertNotEquals(null, true); + testAssertNotEquals(null, new Boolean(true)); + } + + private static void testInteger() + { + testAssertEquals(1, 1); + testAssertEquals(1, new Integer(1)); + testAssertEquals(new Integer(1), new Integer(1)); + testAssertEquals(new Integer(1), 1); + testAssertNotEquals(1, 2); + testAssertNotEquals(new Integer(1), 2); + testAssertNotEquals(1, new Integer(2)); + testAssertNotEquals(1, new Integer(2)); + testAssertNotEquals(1, null); + testAssertNotEquals(new Integer(1), null); + testAssertNotEquals(null, 1); + testAssertNotEquals(null, new Integer(1)); + } + + private static void testAssertEquals(Object left, Object right) + { + Assert.assertEquals(left, right); try { + Assert.assertNotEquals(left, right); + throw new RuntimeException(); + } + catch (AssertionError ignored) + { + } + } + + private static void testAssertNotEquals(Object left, Object right) + { + Assert.assertNotEquals(left, right); + try + { + Assert.assertEquals(left, right); + throw new RuntimeException(); + } + catch (AssertionError ignored) + { + } + } + + private static void testInstanceOf() + { + try + { Assert.assertInstanceOf(null, Object.class); throw new RuntimeException(); } @@ -150,7 +210,7 @@ { } - public static void testObjectEquals() + private static void testObjectEquals() { try { @@ -181,7 +241,7 @@ Assert.assertEquals((Object)null, null); } - public static void testObjectNotEquals() + private static void testObjectNotEquals() { Assert.assertNotEquals(o1, null); Assert.assertNotEquals(null, o1); @@ -212,7 +272,7 @@ } } - public static void testObjectSame() + private static void testObjectSame() { try { @@ -250,7 +310,7 @@ Assert.assertSame(null, null); } - public static void testObjectNotSame() + private static void testObjectNotSame() { Assert.assertNotSame(o1, null); Assert.assertNotSame(null, o1); @@ -274,7 +334,7 @@ } } - public static void testFail() + private static void testFail() { try {

16 years, 7 months

1
0
0 / 0

JBoss Portal SVN: r8712 - branches/JBoss_Portal_Branch_2_6/theme/src/main/org/jboss/portal/theme/page.

by portal-commits＠lists.jboss.org

Author: thomas.heute(a)jboss.com Date: 2007-10-19 05:01:48 -0400 (Fri, 19 Oct 2007) New Revision: 8712 Modified: branches/JBoss_Portal_Branch_2_6/theme/src/main/org/jboss/portal/theme/page/WindowContext.java Log: minor Modified: branches/JBoss_Portal_Branch_2_6/theme/src/main/org/jboss/portal/theme/page/WindowContext.java =================================================================== --- branches/JBoss_Portal_Branch_2_6/theme/src/main/org/jboss/portal/theme/page/WindowContext.java 2007-10-19 01:10:14 UTC (rev 8711) +++ branches/JBoss_Portal_Branch_2_6/theme/src/main/org/jboss/portal/theme/page/WindowContext.java 2007-10-19 09:01:48 UTC (rev 8712) @@ -164,6 +164,6 @@ public String toString() { - return "WindowContext[id=" + id + ",region=" + regionName + ",order=" + order; + return "WindowContext[id=" + id + ",region=" + regionName + ",order=" + order + "]"; } }

16 years, 7 months

1
0
0 / 0

JBoss Portal SVN: r8711 - in modules/test/trunk/docs/user-guide/en: modules and 1 other directory.

by portal-commits＠lists.jboss.org

Author: julien(a)jboss.com Date: 2007-10-18 21:10:14 -0400 (Thu, 18 Oct 2007) New Revision: 8711 Added: modules/test/trunk/docs/user-guide/en/modules/pojotesting.xml Modified: modules/test/trunk/docs/user-guide/en/master.xml modules/test/trunk/docs/user-guide/en/modules/introduction.xml Log: initial checkin of the documentation Modified: modules/test/trunk/docs/user-guide/en/master.xml =================================================================== --- modules/test/trunk/docs/user-guide/en/master.xml 2007-10-19 00:48:05 UTC (rev 8710) +++ modules/test/trunk/docs/user-guide/en/master.xml 2007-10-19 01:10:14 UTC (rev 8711) @@ -2,6 +2,7 @@ <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3CR3//EN" "../../docbook-support/support/docbook-dtd/docbookx.dtd" [ <!ENTITY introduction SYSTEM "modules/introduction.xml"> + <!ENTITY pojotesting SYSTEM "modules/pojotesting.xml"> ]> <book lang="en"> <bookinfo> @@ -16,5 +17,6 @@ </bookinfo> <toc/>  &introduction; +  &pojotesting; </book> Modified: modules/test/trunk/docs/user-guide/en/modules/introduction.xml =================================================================== --- modules/test/trunk/docs/user-guide/en/modules/introduction.xml 2007-10-19 00:48:05 UTC (rev 8710) +++ modules/test/trunk/docs/user-guide/en/modules/introduction.xml 2007-10-19 01:10:14 UTC (rev 8711) @@ -7,52 +7,46 @@ <email>julien(a)jboss.org</email> </author> </chapterinfo> - <title>My title</title> - <para>This section covers the ajax features provided by the portal.</para> + <title>Introduction</title> <sect1> - <title>Introduction</title> + <title>Motivation</title> <para>Todo</para> </sect1> <sect1> - <title>Ajaxified markup</title> + <title>Principles</title> + <para>JBoss Unit clearly separates the different concerns for unit testing an application.</para> <sect2> - <title>Ajaxified layouts</title> - <para>Part of the Ajax capabilities are implemented in the layout framework which provide the structure for - generating portal pages. The good news is that the existing layout only requires a few modifications in - order to be ajaxified.</para> - <para>We will use as example an simplified version of the layout JSP provided in JBoss Portal 2.6 and outline - what are the required changes that makes it an ajaxified layout: - <programlisting><![CDATA[ -<%@ taglib uri="/WEB-INF/theme/portal-layout.tld" prefix="p" %> -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" -"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml"> -<head> - <meta http-equiv="Content-Type" content="text/html;"/> -  - <p:theme themeName="renaissance"/> -  - <p:headerContent/> -</head> -]]></programlisting> - <itemizedlist> - <listitem><![CDATA[<p:theme themeName="renaissance"/>]]> should be already present as it exists since 2.4 but is even more - necessary as it will inject in the page the reference to the ajax stylesheet.</listitem> - <listitem><![CDATA[<p:region regionName='AJAXScripts' regionID='AJAXScripts'/>]]> should be added before any other region - in the markup of the layout.</listitem> - <listitem><![CDATA[<p:region regionName='AJAXFooter' regionID='AJAXFooter'/>]]> should be added after any other region - in the markup of the layout.</listitem> - </itemizedlist> - </para> - <mediaobject> - <imageobject> - <imagedata align="center" fileref="images/sample/partial-refresh.png" format="png"/> - </imageobject> - <caption> - <para>The portal providing partial refresh</para> - </caption> - </mediaobject> + <title>Framework API</title> + <para>Writing a test case often requires the usage of an API in order to perform interactions between the code tested + and the unit test framework. The first thing that a developer does is to declare the different methods of the code + that are subject to be tested. In addition it can also declare how the different tests needs to be parameterized. The + last interaction we recognize is the capability for a developer to perform assertions during the execution of the + test and signal to the unit test framework that it failed. JBoss Unit provides an API for those purposes that leverages + the features of the Java 5 platform such as annotations, generics or statis imports. This API is not tied to the + framework itself which means that the test written will not have to import anything from the framework itself.</para> </sect2> + <sect2> + <title>Test Driver</title> + <para>The test driver is the part of the framework which defines the contract of what a tested system is. It + provides support for retrieving the rich description of the tested system and perform interactions i.e executing + tests.</para> + <para>The goal of this concept is to isolate the tested system from the unit test framework itself. For instance + the testing of POJOs is done via the implementation of a specific test driver that understand how to extract + test description from a POJO and how to test a POJO.</para> + </sect2> + <sect2> + <title>Test Runner</title> + <para>The test runner is the engine of the framework. Indeed the interface exposed by a test driver is very + simple and low level. The test runner provides a framework that can be used to trigger a serie of tests + leveraging one or several test drivers. The definition of the tests to execute is written in an XML file + that contains the base configuration for executing a serie of test. It also provide additional features + such as eventing capabilities and filtering capabilities.</para> + </sect2> + <sect2> + <title>Tooling</title> + <para>Tests are triggered by build systems or from command line, test reporting must also be done in a manner + such as it integrates with other reporting systems. By default the framework comes with support of Ant, Maven + and JUnit XML reporting schema.</para> + </sect2> </sect1> </chapter> Copied: modules/test/trunk/docs/user-guide/en/modules/pojotesting.xml (from rev 8708, modules/test/trunk/docs/user-guide/en/modules/introduction.xml) =================================================================== --- modules/test/trunk/docs/user-guide/en/modules/pojotesting.xml (rev 0) +++ modules/test/trunk/docs/user-guide/en/modules/pojotesting.xml 2007-10-19 01:10:14 UTC (rev 8711) @@ -0,0 +1,228 @@ +<?xml version="1.0" encoding="UTF-8"?> +<chapter id="pojotesting"> + <chapterinfo> + <author> + <firstname>Julien</firstname> + <surname>Viet</surname> + <email>julien(a)jboss.org</email> + </author> + </chapterinfo> + <title>POJO testing</title> + <para>We will describe in this chapter how to write tests for POJOs. We will also cover the integration with JBoss Microcontainer + which allow the setup of complex POJO assemblies which enable to test complex system with a reasonable amount of efforts.</para> + <para>The POJO test API leverages numerous Java 5 features in order to make tests easy to write and read.</para> + <sect1> + <title>The simplest test case</title> + <para>A test cases is public non static method annotated with the <interfacename>@Test</interfacename> annotation. The method + should have en empty list of arguments. At runtime an instance of the class is created and the method is invoked, if the invocation + of the method can be achieved then the test case is considered as a success. Any exception thrown by the method will signal + that the test failed.</para> + <para>A class containing a serie of test cases is considered as a test suite.</para> + <example> + <programlisting><![CDATA[ +import org.jboss.unit.api.pojo.annotations.Test; + +public class MyTest +{ + @Test + public void test() + { + } +} +]]></programlisting> + <caption><filename>MyTest.java</filename></caption> + </example> + <para>In this example the method <methodname>test</methodname> is our test case, and the class <classname>MyTest</classname> + is our test suite.</para> + <para>The various tested items tested must be declared in a file. This file defines what is tested and how it should be. + One interesting thing is that it describes a tested system in an manner independant of the tool which will trigger + your tests (command line, Ant, Maven, ...).</para> + <example> + <programlisting><![CDATA[ +<?xml version="1.0" encoding="UTF-8"?> +<jboss-unit + xmlns="urn:jboss:jboss-unit:1.0" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:jboss:jboss-unit:1.0 jboss-unit_1_0.xsd"> + <pojo> + <test> + <class name="MyTest"/> + </test> + </pojo> +</jboss-unit> +]]></programlisting> + <caption><filename>jboss-unit.xml</filename></caption> + </example> + </sect1> + <sect1> + <title>Making a test fail</title> + <sect2> + <title>Asssertion and errors</title> + <para>We explained in the previous section that a test is considered as failed if it throws an exception during + its execution. There are two categories of failure.</para> + <itemizedlist> + <listitem>Assertion failures: produced by any exception instance of the error <exceptionname>java.lang.AssertionError</exceptionname>.</listitem> + <listitem>Error failures: produced by any exception not instance of the error <exceptionname>java.lang.AssertionError</exceptionname>.</listitem> + </itemizedlist> + <para>JBoss Unit relies on the assertion mechanism introduced by the Java 1.4 platform which introduces the <emphasis>assert</emphasis>. The first + advantage is that we leverage an existing feature of the platform, the second advantage is that it will report assertion + failures that would be in the tested domain.</para> + <para>Obviously throwing instances of <exceptionname>AssertionError</exceptionname> in your code is just an option + that you could use if you want. JBoss Unit comes with its own set of utility methods that can perform various checks and + will throw an <exceptionname>AssertionError</exceptionname> if a condition is evaluated to false. The class + <classname>org.jboss.unit.api.Assert</classname> contains those static methods. The class is final which means that + your code cannot extend it, instead you should rather rely on the static import mechanism in order to import the various + methods needed by your test cases.</para> + <example> + <programlisting><![CDATA[ +import org.jboss.unit.api.pojo.annotations.Test; +import static org.jboss.unit.api.Assert.*; + +public class MyTest +{ + @Test + public void test() + { + fail("Don't freak out"); + } +} +]]></programlisting> + </example> + <para>The <methodname>fail</methodname> method will simply throw a <exceptionname>AssertionError</exceptionname> with the specified message. It will + stop the execution of the test case and it will be considered as an assertion faillure.</para> + </sect2> + <sect2> + <title>Various assertions</title> + + <sect3> + <title><methodname>assertNull</methodname></title> + <programlisting><![CDATA[ +public class MyTest +{ + @Test + public void test() + { + assertNull(null); + } +} +]]></programlisting> + <para>Assert that the argument is null.</para> + </sect3> + + <sect3> + <title><methodname>assertNotNull</methodname></title> + <programlisting><![CDATA[ +public class MyTest +{ + @Test + public void test() + { + String s = assertNotNull("foo"); + } +} +]]></programlisting> + <para>Assert that the argument is not null. The method relies on the generics and returns the same type + of the argument type in order to avoid a type cast, improving the readability of the code.</para> + </sect3> + + <sect3> + <title><methodname></methodname></title> + <programlisting><![CDATA[ +public class MyTest +{ + @Test + public void test() + { + } +} +]]></programlisting> + <para>.</para> + </sect3> + + <sect3> + <title><methodname></methodname></title> + <programlisting><![CDATA[ +public class MyTest +{ + @Test + public void test() + { + } +} +]]></programlisting> + <para>.</para> + </sect3> + + <sect3> + <title><methodname></methodname></title> + <programlisting><![CDATA[ +public class MyTest +{ + @Test + public void test() + { + } +} +]]></programlisting> + <para>.</para> + </sect3> + + <sect3> + <title><methodname></methodname></title> + <programlisting><![CDATA[ +public class MyTest +{ + @Test + public void test() + { + } +} +]]></programlisting> + <para>.</para> + </sect3> + + <sect3> + <title><methodname></methodname></title> + <programlisting><![CDATA[ +public class MyTest +{ + @Test + public void test() + { + } +} +]]></programlisting> + <para>.</para> + </sect3> + + <sect3> + <title><methodname></methodname></title> + <programlisting><![CDATA[ +public class MyTest +{ + @Test + public void test() + { + } +} +]]></programlisting> + <para>.</para> + </sect3> + + <sect3> + <title><methodname></methodname></title> + <programlisting><![CDATA[ +public class MyTest +{ + @Test + public void test() + { + } +} +]]></programlisting> + <para>.</para> + </sect3> + + </sect2> + </sect1> +</chapter>

16 years, 7 months

1
0
0 / 0

JBoss Portal SVN: r8710 - in modules/test/trunk/tooling: src/main/org/jboss/test/unit/tooling and 2 other directories.

by portal-commits＠lists.jboss.org

Author: julien(a)jboss.com Date: 2007-10-18 20:48:05 -0400 (Thu, 18 Oct 2007) New Revision: 8710 Added: modules/test/trunk/tooling/src/main/org/jboss/test/unit/tooling/AssertKeywordTest.java modules/test/trunk/tooling/src/resources/test/assertkeyword-unit.xml Modified: modules/test/trunk/tooling/build.xml modules/test/trunk/tooling/src/main/org/jboss/unit/tooling/ant/TestsType.java Log: by default enable assertions in ant task in order to report errors generated by assert keywords Modified: modules/test/trunk/tooling/build.xml =================================================================== --- modules/test/trunk/tooling/build.xml 2007-10-18 23:31:25 UTC (rev 8709) +++ modules/test/trunk/tooling/build.xml 2007-10-19 00:48:05 UTC (rev 8710) @@ -224,6 +224,9 @@ <exclude id="otherTestTwo"/> </tests> + <tests config="./output/resources/test/assertkeyword-unit.xml"> + </tests> + <!--<tests config="./output/resources/test/bobo-tests.xml"> <include id="testOne"/> <include id="otherTestOne"/> Added: modules/test/trunk/tooling/src/main/org/jboss/test/unit/tooling/AssertKeywordTest.java =================================================================== --- modules/test/trunk/tooling/src/main/org/jboss/test/unit/tooling/AssertKeywordTest.java (rev 0) +++ modules/test/trunk/tooling/src/main/org/jboss/test/unit/tooling/AssertKeywordTest.java 2007-10-19 00:48:05 UTC (rev 8710) @@ -0,0 +1,38 @@ +/****************************************************************************** + * JBoss, a division of Red Hat * + * Copyright 2006, Red Hat Middleware, LLC, and individual * + * contributors as indicated by the @authors tag. See the * + * copyright.txt in the distribution for a full listing of * + * individual contributors. * + * * + * This is free software; you can redistribute it and/or modify it * + * under the terms of the GNU Lesser General Public License as * + * published by the Free Software Foundation; either version 2.1 of * + * the License, or (at your option) any later version. * + * * + * This software is distributed in the hope that it will be useful, * + * but WITHOUT ANY WARRANTY; without even the implied warranty of * + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * + * Lesser General Public License for more details. * + * * + * You should have received a copy of the GNU Lesser General Public * + * License along with this software; if not, write to the Free * + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA * + * 02110-1301 USA, or see the FSF site: http://www.fsf.org. * + ******************************************************************************/ +package org.jboss.test.unit.tooling; + +import org.jboss.unit.api.pojo.annotations.Test; + +/** + * @author <a href="mailto:julien@jboss.org">Julien Viet</a> + * @version $Revision: 1.1 $ + */ +public class AssertKeywordTest +{ + @Test + public void test() + { + assert false : "This test should fail"; + } +} Modified: modules/test/trunk/tooling/src/main/org/jboss/unit/tooling/ant/TestsType.java =================================================================== --- modules/test/trunk/tooling/src/main/org/jboss/unit/tooling/ant/TestsType.java 2007-10-18 23:31:25 UTC (rev 8709) +++ modules/test/trunk/tooling/src/main/org/jboss/unit/tooling/ant/TestsType.java 2007-10-19 00:48:05 UTC (rev 8710) @@ -26,6 +26,7 @@ import org.apache.tools.ant.Project; import org.apache.tools.ant.types.Path; import org.apache.tools.ant.types.Environment; +import org.apache.tools.ant.types.Assertions; import org.apache.tools.ant.taskdefs.Java; import static org.jboss.unit.tooling.ant.ToolingConstants.*; @@ -68,7 +69,6 @@ private Set<Environment.Variable> sysproperties = new HashSet<Environment.Variable>(); - public TestsType() { } @@ -124,6 +124,12 @@ julProperty.setValue("logging.properties"); javaTask.addSysproperty(julProperty); + // We enable by default all assertions : todo make it configurable perhaps (see JDK doc about assertions) + Assertions assertions = new Assertions(); + assertions.setProject(getProject()); + assertions.addEnable(new Assertions.EnabledAssertion()); + javaTask.addAssertions(assertions); + // Beginning of jpda option implementation, need to improve it if (jpda) { Copied: modules/test/trunk/tooling/src/resources/test/assertkeyword-unit.xml (from rev 8705, modules/test/trunk/tooling/src/resources/test/bobo-tests.xml) =================================================================== --- modules/test/trunk/tooling/src/resources/test/assertkeyword-unit.xml (rev 0) +++ modules/test/trunk/tooling/src/resources/test/assertkeyword-unit.xml 2007-10-19 00:48:05 UTC (rev 8710) @@ -0,0 +1,11 @@ +<?xml version="1.0" encoding="UTF-8"?> +<jboss-unit + xmlns="urn:jboss:jboss-unit:1.0" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:jboss:jboss-unit:1.0 jboss-unit_1_0.xsd"> + <pojo> + <test> + <class name="org.jboss.test.unit.tooling.AssertKeywordTest"/> + </test> + </pojo> +</jboss-unit> \ No newline at end of file

16 years, 7 months

1
0
0 / 0

JBoss Portal SVN: r8709 - modules/test/trunk/docs/user-guide/en/modules.

by portal-commits＠lists.jboss.org

Author: julien(a)jboss.com Date: 2007-10-18 19:31:25 -0400 (Thu, 18 Oct 2007) New Revision: 8709 Removed: modules/test/trunk/docs/user-guide/en/modules/sample.xml Log: removed unused file Deleted: modules/test/trunk/docs/user-guide/en/modules/sample.xml =================================================================== --- modules/test/trunk/docs/user-guide/en/modules/sample.xml 2007-10-18 23:30:26 UTC (rev 8708) +++ modules/test/trunk/docs/user-guide/en/modules/sample.xml 2007-10-18 23:31:25 UTC (rev 8709) @@ -1,58 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<chapter id="ajax"> - <chapterinfo> - <author> - <firstname>Julien</firstname> - <surname>Viet</surname> - <email>julien.viet(a)jboss.com</email> - </author> - </chapterinfo> - <title>My title</title> - <para>This section covers the ajax features provided by the portal.</para> - <sect1> - <title>Introduction</title> - <para>Todo</para> - </sect1> - <sect1> - <title>Ajaxified markup</title> - <sect2> - <title>Ajaxified layouts</title> - <para>Part of the Ajax capabilities are implemented in the layout framework which provide the structure for - generating portal pages. The good news is that the existing layout only requires a few modifications in - order to be ajaxified.</para> - <para>We will use as example an simplified version of the layout JSP provided in JBoss Portal 2.6 and outline - what are the required changes that makes it an ajaxified layout: - <programlisting><![CDATA[ -<%@ taglib uri="/WEB-INF/theme/portal-layout.tld" prefix="p" %> -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" -"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml"> -<head> - <meta http-equiv="Content-Type" content="text/html;"/> -  - <p:theme themeName="renaissance"/> -  - <p:headerContent/> -</head> -]]></programlisting> - <itemizedlist> - <listitem><![CDATA[<p:theme themeName="renaissance"/>]]> should be already present as it exists since 2.4 but is even more - necessary as it will inject in the page the reference to the ajax stylesheet.</listitem> - <listitem><![CDATA[<p:region regionName='AJAXScripts' regionID='AJAXScripts'/>]]> should be added before any other region - in the markup of the layout.</listitem> - <listitem><![CDATA[<p:region regionName='AJAXFooter' regionID='AJAXFooter'/>]]> should be added after any other region - in the markup of the layout.</listitem> - </itemizedlist> - </para> - <mediaobject> - <imageobject> - <imagedata align="center" fileref="images/sample/partial-refresh.png" format="png"/> - </imageobject> - <caption> - <para>The portal providing partial refresh</para> - </caption> - </mediaobject> - </sect2> - </sect1> -</chapter>

16 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

portal-commits October 2007