Sometimes it is useful to set up a SoapUI test for simulating different usage scenarios randomly. The following solution provides a random selection from prepared test steps resulting in a different behavior of the tested service.
Schlagwort: Test
The Synology Diskstation DS214play is an Intel based NAS device with 1GB of RAM. It provides a MariaDB and Java support nearly out of the box, both packages are installable using the systems own package manager.
Sonarqube is an ‚continuous inspection‘ formulator providing insights in your code and assuring quality metrics. It is an open platform for managing your code quality which could be enhanced by various plugins for different languages, code metrics and reports.
To install Sonarqube on the DS214play just download thelatest release (at time of writing 4.1.2) from the Sonarqube homepage and unzip it to a directory of your choice on the diskstation. Basically it is possible to run Sonarqube from that point, but it will yield some error messages due to the fact that the diskstation system supports only subset of the command options of a full flavored UNIX installation.
To get Sonarqube started with out error messages inside the gitpid function the pidtest expression must be replaced as shown in the following fragment (new version at line 19):
getpid() {
if [ -f "$PIDFILE" ]
then
if [ -r "$PIDFILE" ]
then
pid=`cat "$PIDFILE"`
if [ "X$pid" != "X" ]
then
# It is possible that 'a' process with the pid exists but that it is not the
# correct process. This can happen in a number of cases, but the most
# common is during system startup after an unclean shutdown.
# The ps statement below looks for the specific wrapper command running as
# the pid. If it is not found then the pid file is considered to be stale.
# not supported by the diskstation environment
#pidtest=`$PSEXE -p $pid -o args | grep "$WRAPPER_CMD" | tail -1`
# trying instead:
pidtest=`$PSEXE | grep $pid | awk '{print($5)}' | grep "$WRAPPER_CMD" | tail -1`
if [ "X$pidtest" = "X" ]
then
# This is a stale pid file.
rm -f "$PIDFILE"
echo "Removed stale pid file: $PIDFILE"
pid=""
fi
fi
else
echo "Cannot read $PIDFILE."
exit 1
fi
fi
}
Sonarqube should startup without any annoyance now, but the stop call will still complain. To fix this to it is needed to replace the second call to the ps command as well (new version at line 6):
testpid() {
# diskstation cannot even handle the following command
#pid=`$PSEXE -p $pid | grep $pid | grep -v grep | awk '{print $1}' | tail -1`
#therefore replace with
pid=`$PSEXE | grep $pid | grep -v grep | awk '{print $1}' | tail -1`
if [ "X$pid" = "X" ]
then
# Process is gone so remove the pid file.
rm -f "$PIDFILE"
pid=""
fi
}
Starting and stopping Sonarqube should now work like a charm and you can focus on the insights of your code.
Working on my new project SynPlayer – an controller to the Synology AudioStation based on C++ and Qt – it becomes evident to set up a testing infrastructure. Keeping dependency small and simple the decision was to facilitate QtTestLib for testing purposes.
In preparation of the upcoming Coursera course „Reactive Programming“ I just want to refresh my Scala skills by porting the Coursera Downloader from Python to Scala.
Setting up the initial build with Gradle is quite easy using the Scala Plugin. Looking around for some testing framework I have chosen Specs2 . Running Gradle after building some simple unit tests shows up that the tests are not executed at all. The build passes without running one single tests. Even declaring the tests to be processed by a JUnit4 runner did not want show up a single tests result. So I came up with the following simple solution. I add a new specs2 task to my Gradle build using the specs2 file runner:
/**
* Run Spec2 tests
*/
task specs(type: JavaExec, dependsOn: testClasses) {
main = 'org.specs2.files'
args = ['console']
classpath sourceSets.main.runtimeClasspath
classpath sourceSets.test.runtimeClasspath
classpath configurations.testRuntime
classpath configurations.runtime
}
The file runner will select all files matching .*Spec in the test source directory which default (src/test/scala) nicely conforms the default project setup. If necessary it could be adjusted by setting the specs2.srcTestDir system property. For more information on the Specs2 Runners refer to the Specs2 documentation.
Now you have only to hook in the test step execution which could be easily achieved by extending the test task to depend on the specs2 tasks as well:
/* * and add them to the default test set */ test.dependsOn specs
Running the test target of the Gradle build once again shows up the execution of the specs2 target and all tests and specifications.
Update(09/04/2014)
Marino Borra points out that he could run the specs tests successfully with the default gradle test task by simply adding the @RunWith(classOf[JUnitRunner]) annotation.