Release 1.0.1 contains some bug fixes and additions suggested in the comments of my blog post about the initial release of XtendTools (see change log for details) and also a complete Javadoc-like API documentation of XtendLib which has been generated using XtendDoc.

As usual, comments, suggestions and contributions are welcome!

I really wished to have something like Javadoc for Xtend!

Well, to cut a long story short, here it is:

XtendDoc is a tool for generating HTML API documentation for the Xtend language. XtendDoc is obviously inspired by Javadoc and uses the same markup language and the generated documentation also looks similar to documentation generated by Javadoc.

You can download a preview version of XtendDoc right here:

• xtenddoc-preview-zip

XtendDoc uses Xtext 1.0 to parse the Xtend files and extract the comments. A good starting point for the Xtend grammar was the expression grammar by Moritz Eyshold and Knut Wannheden. The HTML documentation is generated using Xpand templates.

If you would like to have a look at the source code, or if you would like to participate, feel free to contact me!

You just need the required libraries and the following Ant snippet to run the Xtext generator (or any other MWE2 workflow):

	<path id="gen.classpath">
		<fileset dir="lib" includes="*.jar"/>
		<pathelement location="src"/>
	</path>
 
	<target name="gen">
		<java classname="org.eclipse.emf.mwe2.launch.runtime.Mwe2Launcher" classpathref="gen.classpath" fork="true">
			<arg value="path/to/your/workflow.mwe2"/>
		</java>
	</target>

Using Xtext 1.0 the following libraries are required to run the generator:

antlr-2.7.7.jar
antlr-3.0.1.jar
com.google.collect_0.8.0.v201006161118.jar
com.google.inject_2.0.0.v201003051000.jar
com.ibm.icu_4.2.1.v20100412.jar
de.itemis.xtext.antlr_1.0.0.v201006151527.jar
org.antlr.runtime_3.0.0.v200803061811.jar
org.apache.commons.cli_1.0.0.v20080604-1500.jar
org.apache.commons.logging_1.1.1.v201005080502.jar
org.apache.log4j_1.2.15.v201005080500.jar
org.eclipse.emf.codegen.ecore_2.6.0.v20100614-1136.jar
org.eclipse.emf.codegen_2.6.0.v20100614-1136.jar
org.eclipse.emf.common_2.6.0.v20100614-1136.jar
org.eclipse.emf.ecore.xmi_2.5.0.v20100521-1846.jar
org.eclipse.emf.ecore_2.6.0.v20100614-1136.jar
org.eclipse.emf.mwe.core_1.0.0.v201006150535.jar
org.eclipse.emf.mwe.utils_1.0.0.v201006150535.jar
org.eclipse.emf.mwe2.language_1.0.0.v201006150907.jar
org.eclipse.emf.mwe2.launch_1.0.0.v201006150907.jar
org.eclipse.emf.mwe2.runtime_1.0.0.v201006150446.jar
org.eclipse.xpand_1.0.0.v201006150611.jar
org.eclipse.xtend.typesystem.emf_1.0.0.v201006150611.jar
org.eclipse.xtend.util.stdlib_1.0.0.v201006150611.jar
org.eclipse.xtend_1.0.0.v201006150611.jar
org.eclipse.xtext.common.types_1.0.0.v201006161118.jar
org.eclipse.xtext.generator_1.0.0.v201006161118.jar
org.eclipse.xtext.util_1.0.0.v201006161118.jar
org.eclipse.xtext.xtend_1.0.0.v201006161118.jar
org.eclipse.xtext_1.0.0.v201006161118.jar
stringtemplate-3.1b1.jar

The Xtend Tools are a library of reusable extensions for Xtend/Xpand called Xtend Lib and a set of utility classes for testing Xpand templates and Xtend extensions using JUnit.

Xtend Tools is a utility project hosted at the Fornax Platform, a development platform for tools related to the Model-Driven-Software-Development – MDSD.

Xtend Tools is open source and released under the Terms of the Apache License 2.0.

Using the EMF Builder, an EMF model can be created like this:

def builder = new EmfBuilder(EcorePackage)
def book = builder.EClass( 'Book' ) {
  eStructuralFeatures {
    title = EAttribute ( 'title', eType: EcorePackage.Literals.ESTRING )
    pages = EAttribute ( name: 'pages', eType: EcorePackage.Literals.EINT )
  }
}

I’m planning to use it for unit tests for Xpand templates and Xtend extensions using XpandUnit and XtendUnit from the recently founded open source project Xtend Tools. But you may use it for whatever comes to your mind (as along as you respect the license).

I recognize that there already is a Groovy EMF Builder by Jörn Dinkla, but it is published under the terms of the GPL, which are not appropriate for my intended use. So I had write my own from scratch.

Unfortunately, EasyMock failed to create a mock object for this class, due to a SecurityException. The Exception was raised because the package containing the class was signed and CGLIB was unabled to create a proxy class in the same package.

Caused by: java.lang.SecurityException: class "org.eclipse.emf.mwe.core.WorkflowFacade$$EnhancerByCGLIB$$21bce57e"'s signer information does not match signer information of other classes in the same package
	at java.lang.ClassLoader.checkCerts(ClassLoader.java:775)
	at java.lang.ClassLoader.preDefineClass(ClassLoader.java:487)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:614)
	... 36 more

The solution I found was PowerMock. PowerMock is actually an extension for the popular mocking frameworks EasyMock and Mockito. PowerMock provides additional funktionality especially for testing “legacy code”, that was not designed for testing (e.g. mocking of static members, private members, partial mocking, and more). And PowerMock also supports mocking of classes in signed packages out of the box.

To use PowerMock, you have to use the PowerMockRunner to execute the tests (using the @RunWith annotation in JUnit 4) and tell PowerMock which classes need special treatment (using the @PrepareForTest annotation). Also most calls to the static methods of EasyMock have to be replaced with calls of the equivalent methods of org.powermock.api.easymock.PowerMock.

import static org.easymock.EasyMock.expect;
import static org.junit.Assert.assertEquals;
import static org.powermock.api.easymock.PowerMock.createMock;
import static org.powermock.api.easymock.PowerMock.replay;
import static org.powermock.api.easymock.PowerMock.verify;
import static org.powermock.reflect.Whitebox.invokeMethod;
 
import org.junit.Test;
import org.junit.runner.RunWith;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;
 
import org.eclipse.emf.mwe.core.WorkflowFacade;
...
 
@RunWith(PowerMockRunner.class)
@PrepareForTest({WorkflowFacade.class})
public class MyTest {
 
    ...
 
    @Test
    public void testCheckWorkflow_success() throws Exception {
        WorkflowFacade workflow = createMock(WorkflowFacade.class);
        expect(workflow.check()).andReturn(issues);
        expect(workflow.getIssues()).andReturn(issues).anyTimes();
        replay(workflow);
 
        invokeMethod(cut, "checkWorkflow", workflow);
 
        assertEquals(0, issues.getErrors().length);
        assertEquals(0, issues.getWarnings().length);
        verify(workflow);
    }
}

In my last blog entry I gave a little example, how to call private members using the Java reflection API. PowerMock offers the Whitebox class for the same purpose. The test above demonstrates the use of the Whitebox class to call a private member of my class-under-test.

public class ArrayListTest {
    
    @Test
    public void testFastRemove() throws Exception {
        ArrayList cut = new ArrayList();
        cut.add("Test1");
        cut.add("Test2");
        
        Method m = ArrayList.class.getDeclaredMethod("fastRemove", Integer.TYPE);
        m.setAccessible(true);
        m.invoke(cut, 1);
        
        assert 1 == cut.size();
    }

}

As this breaks encapsulation, you should only use this, if ever, for white box tests.

• Download: fitnesse-xslt-101.zip

The zip file contains style sheets for FitNesse and fit4oaw. However, the only difference is the “branding” of the reports.

I’m using the style sheets to create fancy reports during automated builds via Ant:

<xslt
  in="${target.dir}/fit4oaw.xml"
  out="${target.dir}/fit4oaw.html"
  style="fit4oaw-html.xsl"/>
<xslt
  in="${target.dir}/fit4oaw.xml"
  out="${test-reports.dir}/TEST-fit4oaw.xml"
  style="fit4oaw-junit.xsl"/>

Update: Released new stylesheets including some cosmetic fixes.

At first, add a target to start the FitNesse server.

<target name="fit4oaw.start">
  <java classname="fitnesse.FitNesse" classpathref="fitnesse.classpath" spawn="true" fork="true">
    <arg value="-o"/>
    <arg value="-p"/>
    <arg value="${fitnesse.port}"/>
    <arg value="-d"/>
    <arg value="${basedir}/${fitnesse.dir}"/>
    <jvmarg value="-Dtest.classpath=${toString:fit4oaw.runtime.classpath}"/>
  </java>
</target>

The ${fitnesse.dir} is the directory where FitNesseRoot is located. This should be an absolute path; therefore it’s preprended with ${basedir}. The class path fitnesse.classpath should contain fitnesse.jar, htmlparser.jar and json.jar and any other required jars from the FitNesse distribution. The class path fit4oaw.runtime.classpath should contain your classes directory (your system under test), all oAW dependencies (either from your local eclipse installation or from the maven repository that comes with fit4oaw), the fitnesse.classpath, fit4oaw.jar and any other dependencies required by your tests.

To use the fit4oaw.runtime.classpath in FitNesse just add the following to your FitNesseRoot/content.txt:

!path ${test.classpath}

The add a target to stop the FitNesse server:

<target name="fit4oaw.stop">
  <java classname="fitnesse.Shutdown" classpathref="fitnesse.classpath">
    <arg value="-p"/>
    <arg value="${fitnesse.port}"/>
  </java>
</target>

And last but not least add the target that actually runs the tests and processes the test results:

<target name="fit4oaw.test">
  <java classname="fitnesse.runner.TestRunner" classpathref="fitnesse.classpath" resultproperty="fit4oaw.result">
    <arg value="-v"/>
    <arg value="-xml"/>
    <arg value="${basedir}/${target.dir}/fit4oaw.xml"/>
    <arg value="localhost"/>
    <arg value="${fitnesse.port}"/>
    <arg value="${fitnesse.suite}"/>
  </java>
  <condition property="fit4oaw.failed">
    <not><equals arg1="${fit4oaw.result}" arg2="0"/></not>
  </condition>
  <xslt
    in="${target.dir}/fit4oaw.xml"
    out="${test-reports.dir}/TEST-fit4oaw.xml"
    style="${tool.dir}/fit4oaw/fit4oaw-junit.xsl"/>
</target>

This target executes the test suite ${fitnesse.suite} and sets the property ${fit4oaw.failed} to “true” if tests failed. After that, the test results are transformed (using the XSLT stylesheet fit4oaw-junit) to JUnit-like test results which can be processed by any tools that supports JUnit test results like the junitreport Ant task or Hudson. Hudson even merges the original JUnit test reports with the fit4oaw test reports, so you have all reports in one place.

fit4oaw ist eine Erweiterung von FitNesse; FitNesse ist ein Wiki-basiertes Framework für Akzeptanz-Tests, bei dem die Tests in tabellenform in Wiki-Seiten eingebettet werden. Sogenannte Fixtures interpretieren die Eingaben in den Tabellen, führen die Ensprechenden Tests gegen das zu testende System aus und markieren erfolgreiche und fehlgeschlagene Tests.

fit4oaw bietet nun eine Sammlung von Fixtures an, mit denen sich verschiedene Aspekte von oAW-Generatoren testen lassen. Derzeit liegt fit4oaw in der Version 1.0 vor. Diese Version bietet Fixtures für das Setup (Metamodell initialisieren, Modell laden etc.), Tests von Xtend Expression und rudimentäre Untersützung für Tests von Xpand Templates an. Für die kommende Version 1.1 habe ich in den letzten Tagen einige Fixtures für Tests von Check-Constraints und für Tests Xpand-Templates mit optisch ansprechenderer Darstellung des Diff-Ergebnisses beigesteuert:

XpandTemplate und FileXpandTemplate Fixtures

Die XpandTemplate Fixtures vergleichen die Ausgabe eines Xpand-Templates, das mit einem bestimmte Modell-Element aufgerufen wurden mit dem erwarteten Text, der entweder direkt im Wiki notiert wird oder in einer externen Datei liegt. Das Ergebnis sieht dann etwa so aus:

Check und CheckAll Fixtures

Die Check Fixtures prüfen die Constraints in einer Check-Datei gegen einzelne oder eine Menge von Modell-Elementen. Die erwarteten Fehler und Warnungen werden dann mit den tatsächlichen Fehlern und Warnungen abgeglichen. Das Ergebnis sieht etwa so aus:

Test-Driven MDSD

Mit diesen Werkzeugen ausgerüstet ist es nun möglich, auch Code-Generatoren (M2T) und Modell-Transformatoren (M2M) Test-getrieben zu entwickeln. Aber egal, ob man die Tests vorher oder nachher schreibt, es gibt jetzt jedenfalls eine einfache Möglichkeit Templates, Extensions und Checks zu testen – und keine Ausreden mehr, es nicht zu tun!