BTW, although any single invocation of this function does indeed return an
offset of only a couple hundred seconds, this 'error' is actually
accumulated over all test cases in a module, resulting in a cumulative
error of over an hour for the last tests in the module.
Cheers,
Philip
--On Monday, April 3, 2006 7:09 PM -1000 Philip Johnson
<[EMAIL PROTECTED]> wrote:
Greetings, hackers,
Hongbing discovered the following code in the JUnit sensor today, which
can result in unit test timestamps being up to an hour off when sent to
the server. Does anyone remember writing this code, and remember the
circumstances under which it was needed? We'd like to make the
timestamps a little closer to reality if possible.
Thanks!
Philip
260 /**
261 * Computes a long value from the passed String. Equal strings will
always 262 * compute the same long value and unequal strings will
(usually) compute a different 263 * long value. This value is added on
to the startTime associated with that TestClass (which 264 * is itself
determined by the file's last mod date.
265 * The value computed generally varies between 70,000 and 250,000
(i.e. 70 and 250 seconds). This 266 * hash is used to solve the problem
of multiple files with the same last mod time being sent 267 * by
different sensor shell instances (which results in clobbering of the data
on the server 268 * side.)
269 *
270 * @param testClassName The name of the test class whose hash is to
be computed. 271 * @return A hash value (generally between about 70,000
and 250,000). 272 */
273 private long computeFileHash(String testClassName) {
274 long hash = 0;
275 for (int i = 0; i < testClassName.length(); i++) {
276 hash += (testClassName.charAt(i) * i);
277 }
278 return hash;
279 }
