First Unit Test
Ricky Romero
First of all, apologies to people who were watching my fork who got
unwatched. I blew away my fork and recreated it in a fit of trying to
get the fork up to date from mde's master. :-)
This is my first stab at a proper unit test. It's dirty, but it gets
the job done.
http://github.com/RickyRomero/timezone-js
Best use Safari if you're running all the tests since it seems to blow
through them fastest. Chrome seems to hang indefinitely, and Firefox
is pretty quick but not *as* quick as Safari.
The main test builds out a table with the TZID, the number of tests
run, the number total, and the percentage that were correct as
compared to zdump's output from Mac OS X 10.6.3 and whatever tz
database it has installed.
I've also included a function that will let you run tests piecemeal,
if you're trying to troubleshoot one particular TZID.
Next thing I want to add is another column or something with a nested
table of all the failures, so you can see exactly how a test is
failing. But for tonight, this is what you get. :-P
Ricky
Jan Niehusmann
On Mon, Apr 05, 2010 at 01:55:21AM -0700, Ricky Romero wrote:
> Best use Safari if you're running all the tests since it seems to blow
> through them fastest. Chrome seems to hang indefinitely, and Firefox
> is pretty quick but not *as* quick as Safari.
With Firefox, I always get timeout errors, unfortunately. Perhaps it's
because I still have firefox 3.5.8. Did you try it with 3.6?
However, I guess it's possible to solve that, and it looks like a nice
thorough test set. For quick tests to verify changes during development,
I'd prefer to have a faster test available, though. What about leaving
test.html as it was, and putting your test set to a new file like
fulltest.html or longtest.html?
> The main test builds out a table with the TZID, the number of tests
> run, the number total, and the percentage that were correct as
> compared to zdump's output from Mac OS X 10.6.3 and whatever tz
> database it has installed.
As the time zone database is updated regularly, it would be very useful
to be able to regenerate the test set from the raw time zone data. As
you probably didn't write all these tests by hand, could you provide the
source code you used to generate them?
Regards,
Jan
PS: commit 56e36e26aad5be98ed11f08e199045b44906d1f7 does contain some
unexplained changes to src/date.js, which look as if they were not
directly connected to the tests. If they fix some issue, it's probably
better to submit them in a separate patch.
Ricky Romero
> Hi Ricky,
>
> On Mon, Apr 05, 2010 at 01:55:21AM -0700, Ricky Romero wrote:
> > Best use Safari if you're running all the tests since it seems to blow
> > through them fastest. Chrome seems to hang indefinitely, and Firefox
> > is pretty quick but not *as* quick as Safari.
>
> With Firefox, I always get timeout errors, unfortunately. Perhaps it's
> because I still have firefox 3.5.8. Did you try it with 3.6?
Yep, I tested it with 3.6.3.
> However, I guess it's possible to solve that, and it looks like a nice
> thorough test set. For quick tests to verify changes during development,
> I'd prefer to have a faster test available, though. What about leaving
> test.html as it was, and putting your test set to a new file like
> fulltest.html or longtest.html?
Good idea. I think I might do a few things:
1.) Separate out the longer test into a separate file, like you said.
2.) Set up the long series of tests using setTimeout so that the
browser has some idle time to catch up, render the output, and
generally be more responsive.
3.) Have another page with a text field where you can just paste in
the zone you want to test, and it will output a miniature table of the
results.
> > The main test builds out a table with the TZID, the number of tests
> > run, the number total, and the percentage that were correct as
> > compared to zdump's output from Mac OS X 10.6.3 and whatever tz
> > database it has installed.
>
> As the time zone database is updated regularly, it would be very useful
> to be able to regenerate the test set from the raw time zone data. As
> you probably didn't write all these tests by hand, could you provide the
> source code you used to generate them?
The script I wrote to generate this information goes through and uses
the zoneinfo database that's already installed in the system. And
it's written as a .kon file (for Yahoo! Widgets). :-P
So I'd want to:
1.) Rewrite it in PHP or something
2.) Test if zic will enable me to compile and install new zoneinfo
data
> PS: commit 56e36e26aad5be98ed11f08e199045b44906d1f7 does contain some
> unexplained changes to src/date.js, which look as if they were not
> directly connected to the tests. If they fix some issue, it's probably
> better to submit them in a separate patch.
The new "replace" call is a more reliable method of stripping
comments. There are some rules where there's a comment on its own
line in the middle of a time zone rule or whatever, and those were
being put in as empty array entries in the rules when the script
parsed the Zoneinfo files. They became apparent as a problem when I
was doing dry runs of this test suite.
I made the change at the end of the file to get the series of tests
past America/Anchorage, as one of the tests in that zone tried to
fetch a time zone abbreviation that wasn't there, and it was throwing
an error that was stopping the test. Obviously this is just masking a
larger problem, but I intend to expose it in the next update, which
will also test the time zone abbreviations.
I'll go ahead and document these changes in my commit.
There's another problem too, which is commented out with a FIXME in
the test suite: date.js is throwing errors from line 399 on zones
that resolve to Etc/GMT or Etc/UTC. This appears to be a deeper
problem stemming from date.js not reading the etcetera ZoneInfo file.