[PATCH weston v6 2/4] Enables output in the JUnit XML format.

[Pekka Paalanen]

On Wed, 15 Jul 2015 17:21:16 -0700
"Jon A. Cruz" <jonc at osg.samsung.com> wrote:

> On 07/07/2015 04:49 AM, Pekka Paalanen wrote:
> > On Thu,  2 Jul 2015 23:36:45 -0700
> > "Jon A. Cruz" <jonc at osg.samsung.com> wrote:
> > 
> >> Adds basic support for optionally outputting in the XML format
> >> commonly used by JUnit compatible tools.
> >>
> >> This format is supported by default by many tools, including
> >> the Jenkins build system. It also is more detailed and
> >> captures more information than the more simplistic TAP
> >> format.
> >>
> >> Signed-off-by: Jon A. Cruz <jonc at osg.samsung.com>
> >> ---
> >>  Makefile.am                           |   9 +
> >>  configure.ac                          |  26 ++
> >>  tools/zunitc/src/zuc_junit_reporter.c | 488 ++++++++++++++++++++++++++++++++++
> >>  tools/zunitc/src/zuc_junit_reporter.h |  38 +++
> >>  tools/zunitc/src/zunitc_impl.c        |  17 ++
> >>  5 files changed, 578 insertions(+)
> >>  create mode 100644 tools/zunitc/src/zuc_junit_reporter.c
> >>  create mode 100644 tools/zunitc/src/zuc_junit_reporter.h

> >> +char *
> >> +as_duration(long ms)
> >> +{
> >> +	char *str = NULL;
> >> +	if (asprintf(&str, "%1.3f", ms / 1000.0) < 0) {
> >> +		str = NULL;
> >> +	} else {
> >> +		if (!strcmp("0.000", str)) {
> >> +			free(str);
> >> +			str = strdup("0");
> > 
> > That's a funny sequence. Why is 0.000 bad?
> 
> Comment added in code for explanation.
> 
> "0.000" is bad since existing test frameworks avoid it. To keep safely
> compatible with various tools that read JUnit style output, what is
> written should be kept 100% identical where possible.

I still don't understand what could it break. It's not used to
distinguish a true 0 from a non-zero value that rounds to 0.000 during
printing either.

Someone would have to go out of their way to explicitly fail parsing if
the result is 0 but the string was not "0".

Smells like cargo-cult...

Oh well, whatever.


Thanks,
pq