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 14:20:38 -0400


Maybe we're both looking at the latest but I'm not seeing the problem.

So we have for example on line 706:

assertWithMessage("Start time of job occurs no sooner than start time of
test",                                  
ts.compareTo(execution1.getStartTime()) <=
0);

You wrote:
        ...On my laptop, I'm getting intermittent failures due to the fact
that the times are ending up being equal.

But equal times results in a compareTo() value of '0', which should pass
with a <=0 check, right?

------------------------------------------------------
Scott Kurz
WebSphere Batch / Compute Grid Development
T/L 295-5649;
External Phone 845-435-5649

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



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



Scott,

I just pulled the latest from the git repo on java.net and as you can see
in the listing here, the test is still verifying via <=.  Also, I
re-downloaded the zip file and got the same results.  Unfortunately the git
commit log is a bit sparse so I can't see if the changes were overwritten.
Any insight you can provide is appreciated.  Thanks in advance!

Thanks,
Michael Minella

Thanks,
Michael Minella

http://www.michaelminella.com


On Wed, Aug 14, 2013 at 11:57 AM, Scott Kurz 
< >
 wrote:
  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
  

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

  Inactive hide details for Michael Minella ---08/14/2013 12:43:48 PM---In
  the MetricsTests#testMetricsJobExecutionTimestamps() mMichael Minella
  ---08/14/2013 12:43:48 PM---In the
  MetricsTests#testMetricsJobExecutionTimestamps() method, the assertions
  at the end validate t

  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