Skip to main content

[jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

  • From: Scott Kurz < >
  • To:
  • Subject: [jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight
  • Date: Wed, 14 Aug 2013 12:57:51 -0400


Michael,

We actually fixed the issue of wrongly failing on equal timestamps already
(we didn't do anything about the time format).

We actually fixed it before the TCK version we tagged as "final" (from
4/22), though it was in very similar form before that final release so I
don't blame anyone who missed the fine print there.

Let me take this opportunity to point you to our TCK change history:
https://java.net/projects/jbatch/pages/TCK_ChangeHistory

As I wrote here, we're of course, not going to be changing TCKs without a
careful justification (excepting the case when it's a very minor change).

And the latest TCK (6/27) is at:
https://java.net/projects/jbatch/downloads/download/jsr352-tck-1.0.zip

Thanks for bringing this up,
------------------------------------------------------
Scott Kurz
WebSphere Batch / Compute Grid Development
T/L 295-5649;
External Phone 845-435-5649

--------------------------------------------------------



From:   Michael Minella 
< >
To:     
" "
 
< >,
Date:   08/14/2013 12:43 PM
Subject:        [jsr352-public] MetricsTests#testMetricsJobExecutionTimestamps
            assertions too tight



In the MetricsTests#testMetricsJobExecutionTimestamps() method, the
assertions at the end validate that the job creation timestamp is not less
than or equal to the start time for the test.  On my laptop, I'm getting
intermittent failures due to the fact that the times are ending up being
equal.  I would think that the test should validate that the time was not
before but equal should be ok in this instance.  The same scenario occurs
in MetricsTests#testMetricsStepTimestamps.

As a side note, it would be helpful if the reporter output actually
specified a date format instead of relying on toString so that consistent
output is generated from the test and the implementation.

testMetricsJobExecutionTimestamps
    Create job parameters for execution #1:


    app.processFilterItem=3


    Locate job XML file: testMetricsCommitCount.xml


    Invoke startJobAndWaitForResult for execution #1


    execution #1 JobExecution getBatchStatus()=COMPLETED


    AJM: testcase start time: Wed Aug 14 10:30:52 CDT 2013


    AJM: job create time: 2013-08-14 10:30:52.863


    AJM: job start time: 2013-08-14 10:30:52.864


    AJM: job last updated time: 2013-08-14 10:30:52.878


    AJM: job end time: 2013-08-14 10:30:52.878




testMetricsStepTimestamps
    Create job parameters for execution #1:


    app.processFilterItem=3


    Locate job XML file: testMetricsCommitCount.xml


    Invoke startJobAndWaitForResult for execution #1


    Obtaining StepExecutions for execution id: 112


    execution #1 JobExecution getBatchStatus()=COMPLETED


    AJM: testcase start time: Wed Aug 14 10:30:53 CDT 2013


    AJM: step start time: 2013-08-14 10:30:53.73


    AJM: step end time: 2013-08-14 10:30:53.74


Thanks,
Michael Minella

http://www.michaelminella.com

GIF image



[jsr352-public] MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

Michael Minella 08/14/2013

[jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

Scott Kurz 08/14/2013

[jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

Michael Minella 08/14/2013

[jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

Scott Kurz 08/14/2013

[jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

Michael Minella 08/14/2013

[jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

Scott Kurz 08/15/2013

[jsr352-public] Re: MetricsTests#testMetricsJobExecutionTimestamps assertions too tight

Michael Minella 08/15/2013
 
 
Close
loading
Please Confirm
Close