Re: [Cs-studio-core] Testsuite

[Kasemir, K. <kas...@or...>]

Hi:

Looks like we all want the same thing.

As for using file names vs. annotations to locate the tests:
File names are easier for humans, you see it right away.
With annotations you first have to open the file.
Use of file names might also be better for ant build.xml files, where I can
easily filter on plain Junit tests:

    <target name="tests" depends="compile">
        <junit ...>
            ...
            <batchtest todir="${tests}">
                <fileset dir="${src}">
                    <include name="**/* UnitTest.java" />
                </fileset>
            </batchtest>
        </junit>
    </target>

With annotations, I think you have to write Java code that then looks for
all the annotations.

> I'd still prefer to scan all classes for being a test, and notify the
> user for a class not adhering to the pattern....
Good idea.

I've started https://sourceforge.net/apps/trac/cs-studio/wiki/UnitTests
where we can document the names and/or annotations.

>> ""Don't use System.out. That hangs when there's no console""
>> ??? Really ???
> Observed when plugin-test environment with css product running and ui
> components. Removing the syso worked then, but I don't know yet the
> exact reason.
Especially in Hudson reports of failed tests I found it useful to have the
sysout text that shows in more detail why the test failed, so it would be
good to figure out why sysout caused problems.

> I'm not yet confident with the site specific switch residing in the jvm
> args of the 'all tests'-launch configuration (as I did it for now).

> its way into the shared repo. Perhaps, in anybody's eclipse ide as sys
> property configured in the eclipse.ini, where we typically put things
> like -Duser.name=bknerr and so on. We could put there e.g. -DsiteId=SNS.
Maybe eclipse.ini is better, because it's more 'global' and you don't have
to remember it for each launch configuration.

Whatever you pick, just add it to the wiki page.

Thanks,
Kay