I am using JUnit4 and want to put some extra information to be displayed in JUnit reports.
For this, I shall be dumping the extra information to the report xml and then modify the xslt to read that extra information to generate the HTML report.
Steps so far that are working are:
Copied all the code from XMLJUnitResultFormatter to MyFormatter.java and modified the endTest() method to add that extra information in the form of an extra attribute to testcase XML tag.
This is really bad :( but I could not simply override it as there usages of the private instance variables directly without getters/setters in endTest() method.
My junit ant task:
<junit fork="yes" printsummary="withOutAndErr">
<!--<formatter type="xml"/>-->
<formatter classname="com.some.junit.MyFormatter" extension=".xml"/>
<test name="com.some.source.MyTestClassTest" todir="${junit.output.dir}"/>
<classpath refid="JUnitProject.classpath"/>
</junit>
Modified the xslt to read the extra attribute of TESTCASE xml tag and display in report.
My modified ant task for report:
<target name="junitreport" depends="MyTestClassTest">
<junitreport todir="${junit.output.dir}">
<fileset dir="${junit.output.dir}">
<include name="TEST-*.xml"/>
</fileset>
<report styledir="reportstyle" format="frames" todir="${junit.output.dir}"/>
</junitreport>
</target>
I came across using TestNG nor SureFire Maven plugins as solutions, but I can't use them in my project.
Is there any better way than this in JUnit4?
Maybe?
The interface org.apache.tools.ant.taskdefs.optional.junit.JUnitResultFormatter is what needs to be implemented for a custom output format. This could write to any output stream, which is all the extensiblity that was built into the framework. You are right, there isn't a good way to extend the capabilities of XMLJUnitResultFormatter to customize the output. A copy-paste-modify certainly isn't ideal, but certainly acceptable.
Another approach might be to have more than one formatter defined in your ant task. One could be the regular xml formatter, with another being your custom one for additional information. These two files could be combined and then turned into HTML using xsl transforms.
I leave it to you to decide if this a better method than you had devised.
Related
I'm not very familiar with JUnit, but I'm attempting to translate an ant target that makes use of junit into the gradle equivalent. It's not going so hot, since I'm getting some failures on the gradle side -- I'm under the impression that it's due to inputs not being found somehow/somewhere, but I can't confirm, since it's not readily present in the ant target.
Here's the ant script:
<target name="testing">
<junit printsummary="yes" showoutput="yes">
<classpath refid="classpath"/>
<formatter type="xml"/>
<batchtest fork="yes" todir="someOutputLocation">
<fileset dir="${base}/testCode">
<include name="**/included.java"/>
<exclude name="**/excluded.java"/>
</fileset>
</batchtest>
</junit>
</target>
And here's (one of the variations) of my gradle attempt:
task testing(type:Test){
useJUnit()
testClassesDir = file("testCodeCompiled")
include '**/included.class'
exclude '**/excluded.class'
classpath = classpath
}
The two errors I get:
junit.framework.AssertionFailedError
java.lang.NullPointerException
The AssertionFailedError is supposedly caused by multiple JUnit dependencies, which I don't have. I import a local version of only junit-4.11.
I really don't know why it's not working, though I suspect it's due to some of gradle's complexities. I've seen people mention an ant-junit library, which I may try to use to at least replicate the results from within gradle.
EDIT: A thought occurs: I found JUnit within some of gradle's src files. By calling useJUnit(), I may be using that instead? If so, there could be a double dependency after all? Nope. Got rid of useJUnit() and the local jar separately. The former behaved as it did before whereas the latter exploded.
MORE INFO: The cause may likely be that the compiledTestCode is missing several of the directories/data that testCode contains. I probably have to copy over the relevant files. Alternatively, is there a way to make gradle's JUnit use .java files instead of .class?
For those of you wondering, the code is fine. I'm just dumb.
I would like to apply the JPA 2.0 Criteria API to a Hibernate legacy application in order to get type-safe queries. Manual model creation is not an option; neither is the introduction of annotations (i.e. converting *.hbm.xml mappings into JPA annotations).
I tried to use Hibernate's "hibernate-jpamodelgen-4.3.6.Final.jar" generator without luck so far. The idea was to have a "dummy" entity to kick in Hibernate's annotation processor (JPAMetaModelEntityProcessor). Then, so my hopes, JPAMetaModelEntityProcessor would detect persistence.xml and would eventually be smart enough to also detect XML configured entities.
That's a real pity that three years after this question was asked, with Hibernate v. 5.2.12, it's still not easy to find how to generate metamodel without use of annotations. Anyway I am going to describe my solution here as this question (without any answer) pops up as the search result for the query "Generate metamodel without annotations". I struggled a bit with this task, but after all I got there with this ANT task:
<target name="jpa_metamodel">
<delete dir="..\\src_tmp"/>
<copy todir="..\\src_tmp">
<fileset dir="..\\src">
<include name="my/model/package/*.java"/>
<include name="META-INF/**/*.xml"/>
</fileset>
</copy>
<replace file="../src_tmp/my/model/package/AbstractEntity.java" token="class" value="#javax.persistence.Entity class"/>
<javac srcdir="..\\src_tmp"
destdir="..\\src_jpa_generated"
failonerror="true"
fork="false">
<compilerarg value="-proc:only"/>
<compilerarg line="-s ..\\src_jpa_generated"/>
<compilerarg line="-Adebug=true"/>
<classpath>
<fileset dir="..\\dependencies\\hibernate">
<include name="**\\*.jar"/>
</fileset>
<pathelement location="../src_tmp"/> <!-- to put META-INF in classpath -->
</classpath>
</javac>
</target>
Problems with Hibernate medamodel generator are:
/META-INF/persistence.xml and /META-INF/orm.xml are searched in classpath, and not in source folder. However it seems to be not enough, because after mapping XMLs are added to classpath they are correctly discovered and generator processes mentioned classes (log entries for every class are emitted), but still, for some reason, no output is produced. So to the next step...
It seems that it's not really possible to go further without actual annotation. Or maybe it is, but I still don't know how, but I can live with simple workaround. I simply automatically add #Entity annotation to temporarily copied sources. Actually I add the annotation in only one file, but in my case it happens to be a root of my entity hierarchy. This might have a meaning, and might not - I did not bother checking. However the need for this step indicates it might be difficult (impossible?) to generate metamodel for entity classes compiled without annotations.
You need to remember about -s compiler arg to store generated *.java files somewhere.
Hope this might be helpful for someone in the future.
I am running find bugs in ant and am trying to set everything (attributes, options, etc) in my ant build.xml to the most sensitive settings for finding bugs. From reading the documentation and looking at example here is what I concluded will be the most sensitive settings for if a bug is ran into. If it is not please let me know any attribute, options, etc that needed to be added or changed to find all the bugs that may be in my code.
<target name="findbugs" depends="jar">
<findbugs home="/home/me/Desktop/findbugs"
output="html"
outputFile="bc.html"
effort="max"
reportLevel="low"
workHard="true"
debug="true">
<auxClasspath path="../foo/bin"/>
<auxClasspath path="../bar/bin"/>
<sourcePath path="../foo2/src" />
<class location="bin/"/>
</findbugs>
</target>
No need for workHard="true" since you already have effort='max'. They're just synonyms of each other. Otherwise, it looks like you have it.
There are includeFilter and excludeFilter, but if you don't list either of those, you get all bugs.
I'm trying to work out how I can run an ant task without actually needed a build.xml.
In particular I want to run a JUnit task with a formatter. In xml format this looks like below:
<junit printsummary="true" errorProperty="test.failed" failureProperty="test.failed">
<classpath refid="run.class.path" />
<!-- console log -->
<formatter type="xml" classname="be.x.SFFormatter" />
<test name="be.x.SF" outfile="result" todir="${build.output.dir}" />
</junit>
It works when running the ant script, but I would like to get my app running as a runnable jar.
Running the tests from Java was easy:
JUnitCore junit = new JUnitCore();
testResult = junit.run(SeleniumFramework.class);
However, I struggle to work out how to actually get the formatter to work.
The formatter is of type org.apache.tools.ant.taskdefs.optional.junit.JUnitResultFormatter so I doubt I can just plug it in somewhere without running ant.
Has anyone done something similar before?
Thanks!
Ant doesn't do any magic. All it does is read the XML file, create the beans specified in it and then execute the methods as per the Task API (org.apache.tools.ant.Task).
So all you need is to do the same in your code. Don't forget to create a Project :-)
You may use Ant via Groovy to avoid the xml syntax.
See => Using Ant from Groovy for details.
We have our TeamCity builds set up using a build chain, so that our unit tests and and integration tests can run in parallel when triggered by a commit:
Build Chain - dependant on:
Unit tests
Integration tests
I am looking for a way that we can combine/merge the coverage data generated by the unit and integration tests in the build chain, so that we can get a better picture of how much actual code is covered by the two combined.
The plan then is to be able to monitor changes in coverage of committed code, and perhaps failing builds if percentages fall!
I have set up the 'build chain' target so that the coverage files (*.em, *.ec) from the unit and integration targets are available to it.
I created an ant build file specifically for the build chain target (with help from the emma doco!):
<project name="coverage-merge" basedir="." default="all">
<!-- directory that contains emma.jar and emma_ant.jar: -->
<property name="emma.dir" value="${basedir}/lib"/>
<property name="coverage.dir" location="${basedir}/coverage"/>
<path id="emma.lib">
<pathelement location="${emma.dir}/emma-teamcity-3.1.1.jar"/>
<pathelement location="${emma.dir}/emma_ant-2.0.5312.jar"/>
</path>
<taskdef resource="emma_ant.properties" classpathref="emma.lib"/>
<target name="all" depends="-report"/>
<target name="-report">
<emma>
<report sourcepath="${src.dir}" sort="+block,+name,+method,+class"
metrics="method:70,block:80,line:80,class:100">
<infileset dir="${coverage.dir}" includes="**/*.em, **/*.ec"/>
<!-- for every type of report desired, configure a nested
element; various report parameters
can be inherited from the parent <report>
and individually overridden for each report type:
-->
<txt outfile="${coverage.dir}/coverage.txt" depth="package"
columns="class,method,block,line,name"/>
<xml outfile="${coverage.dir}/coverage.xml" depth="package"/>
<html outfile="${coverage.dir}/coverage.html" depth="method"
columns="name,class,method,block,line"/>
</report>
</emma>
</target>
</project>
...which merges all the coverage files into a single report!
The metrics parameter of report sets the highlight threshold for the html report, so that the percentages against packages and files that are lower than the threshold are highlighted in red.
Modifying the xml output will allow me to use something like andariel to run an xpath over the results, and then force the build to fail if thresholds are not met!
Per TC's Emma doc
All coverage.* files are removed in the beginning of the build, so you have to ensure that full recompilation of sources is performed in the build to have the actual coverage.em file.
What I did to workaround this is below:
Use -out emma.em in teamcity build steps config, and make sure merge option is set to true to preserve the instrumented data.
In the last step when coverage report is generated, use ant's move task
<move file="$YOUR_PATH/emma.em" tofile="$YOUR_PATH/coverage.em"/> to rename to the default one.
The emma report will pick up the default em file to generate report.
Hope this helps whoever whats to have an accumulated emma coverage report.
Most of the code coverage tools I've encountered do not seem to have a way to combine test results from different or overlapping subsystems. As you have pointed out, this is a very useful ability.
Our SD Test Coverage tools do have this ability and are available for Java, C, C++, C#, PHP and COBOL. In fact, the SD test coverage tools can combine test coverage data from multiple languages into a single monolithic result, so that you can get an overview of test coverage for your multi-lingual applications. It is able to show the coverage on all the source langauges involved, as well as provide summary reports.