|
|
Re: etunit [message #988886 is a reply to message #988747] |
Mon, 03 December 2012 14:47 |
Thomas Schuetz Messages: 31 Registered: January 2010 |
Member |
|
|
Hi Tim,
here some more information about etUnit:
The basic idea is to do the tests for actors with actors (possible on all levels of granularity) and to report all as XUnit XML file.
You will find some examples for etUnit in
http://git.eclipse.org/c/etrice/org.eclipse.etrice.git/tree/tests/org.eclipse.etrice.generator.common.tests/models
Have a look at ChoicePointTest.room (git link or attachment)
This test can be generated in Java and C (and soon in C++)
Code and explanations (ChoicePointTest.room):
- Constructor and Destructor open and close the testcase. You have to memorize the caseId. Be aware that this testcase is a pure whitebox test for testing the codegenerator by generating, compiling and running the code (in case you wonder about this useless statemachine)
- Then you can use the EXPECT_ functions more or less like in JUnit -> a failed EXPECT will not end the testcase, but will stop the reporting (e.g. to avoid problems with EXPECTS in loops)
You will find the interfaces for java and C in:
http://git.eclipse.org/c/etrice/org.eclipse.etrice.git/tree/runtime/org.eclipse.etrice.runtime.java/src/org/eclipse/etrice/runtime/java/etunit/EtUnit.java
and
http://git.eclipse.org/c/etrice/org.eclipse.etrice.git/tree/runtime/org.eclipse.etrice.runtime.c/src/common/etUnit/etUnit.h
- the EXPECT_ODER is something special for testing the order of execution of code fragements. We use it e.g. for testing the order of entry, exit, action codes in hierarchical FSMs with history (not a simple task). The resultlist defines the order.
- since you can run several testcases concurrently (usually one actor per testcase), we can not directly write the XUnit XML report. So we write the .etunit file first (see ChoicePointTest.etu). Then we sort, merge and transform the etunit files with a little helper into the XUnit (see JavaChoicePointTest.xml). The report can be directly viewed in Eclipse (JUnit view) or be used for the Testreporting of our Hudson Server (https://hudson.eclipse.org/hudson/job/mdt-etrice-nightly/lastCompletedBuild/testReport/org.eclipse.etrice.generator.java.tests/)
The converter code: http://git.eclipse.org/c/etrice/org.eclipse.etrice.git/tree/plugins/org.eclipse.etrice.etunit.converter
You see, we develop everything to work also for continuous integration. Here the CI-Project for eTrice at eclipse.org: https://hudson.eclipse.org/hudson/job/mdt-etrice-nightly/
We also use hudson for our customer projects. Very useful.
For our safety relevant systems (automotive) we are working on a combinatorial testcase generator on model level. This might be also useful for other applications.
With a special test DSL you can specify a model of an expected (not an implemented) behavior and generate testcases to cover and check all branches (including data combinations) of your code.
Here the first Grammar for the test language (in case you like to read in EBNF): http://git.eclipse.org/c/etrice/org.eclipse.etrice.git/tree/plugins/org.eclipse.etrice.generator.fsmtest/src/org/eclipse/etrice/generator/FSMtest.xtext
If you need anything else, let us know.
- Thomas
|
|
|
Powered by
FUDForum. Page generated in 0.01540 seconds