WIP: Feature/calendar unit test

[kaiyuan01]

Added unit test for calendar. It will also print meaningful info to the console such as:

[LingDong-]

Make sure the tests still work next year :)

[kaiyuan01]

It will fail soon I know. This is limited by current lib. We may need a way to tell the calendar info, when given a date

[LingDong-]

Please consider adding test cases for the 彼 versions (e.g. 彼年何年) instead. These should be current-date-agnostic. The 今 versions directly call 彼 versions, so their correctness is trivial to prove when 彼 pass the tests.

@statementreply , Since you're probably most familiar with the implementation details, could you please kindly give some insights if possible?

[kaiyuan01]

Current test result:

[statementreply]

Currently, 彼 functions takes a Unix timestamp (UTC), and converts to Chinese calendar date/time of local time, so they are affected by the runtime time zone setting.

[kaiyuan01]

施「彼年何年」於四千七百一十六
Should we name it "彼時何年" instead of "彼年何年" to avoid confusion since the input is in secs instead of years? https://github.com/LingDong-/wenyan-lang/issues/489

[kaiyuan01]

@statementreply Can you also help with the question below (a few functions like this did not work somehow)?

https://github.com/LingDong-/wenyan-lang/issues/488

Thanks.

[kaiyuan01]

Another failed test case for function "言百內數", can you help @statementreply . See the build logs below for error details

[kaiyuan01]

The latest: 1 new function passed, 3 failed (may have to be fixed in lib), see build log for details.

[kaiyuan01]

Done with calendar unit test suite. Please review/merge

[LingDong-]

Thanks so much for the new tests! Just wondering about a couple things:

Is there a reason the examples are not collected in one place but instead spanned across a bunch of files with just 1-2 lines, breaking the original structure of ./examples folder? Is there a reason examples.test.js is not used, but instead an almost identical file is duplicated with the same contents just to test the calendar? Has the problem of timezones in Unix timestamp been somehow addressed in the tests?

I propose that since the calendar involves many calculations similar to num2hanzi, we can create a file of similar structure to hanzi2num.test.js. This way we can also do some tricks in the JS to perhaps work around the fact that the functions depend on the current time & timezone. A compile step has to be involved to do so however, unlike hanzi2num which is in JS. If you're uncomfortable writing that I'm more than happy to help!

"wenyan" is styled without the hyphen in the middle, btw.

Thanks!

[kaiyuan01]

The reason why I wanted to separate some calendar test cases from examples is that when one test case fails inside the .wy file in examples it's very difficult to know the root cause. The new unit tests also print more info to the screen so you can tell what got tested and the status. I am also open to your suggestions so feel free to make the changes as you see fit.

[LingDong-]

Understood. I'll look into it and make some fixes, thanks!

[antfu]

I have made a quick review. Please check it out. Thanks!

[antfu]

The problem seems to from this.

-  path.resolve(__dirname, "../examples/.calendar" + x + ".wy"),
+  path.resolve(__dirname, "../examples/calendar",  x + ".wy"),

[antfu]

The npm t should run all the tests. This extra action config seems to be not necessary.

[antfu]

You should also run npm run test:update and include the snapshots to the commits.

[antfu]

@kaiyuan01

The new unit tests also print more info to the screen so you can tell what got tested and the status.

To my knowledge, tests should not output anything when it passes. It only outputs when it failed. Too many outputs can overhaul the test result.

[LingDong-]

@antfu. Thanks for the review! I think it might be better to test the calendar similar to how we test hanzi2num, perhaps like so (haven't tried it, just an idea):

var assert = require("assert");
var { compile } = require("../src/parser");
var utils = require("../tools/utils")

var compile_options = {
  romanizeIdentifiers: "none",
  lib: utils.loadlib(),
  logCallback: ()=>0,
}

describe("calendar", () => {
  describe("言彼之時刻", () => {
    it("should test calendar stuff", () => {
      assert.strictEqual(
        eval(compile("吾嘗觀「「曆法」」之書。方悟「言彼之時刻」之義。施「言彼之時刻」於四千七百一十四。書之", compile_options)),
        "戌正一刻三分三十四秒"
      );
    });
  });

  describe("言彼之日時", () => {
    it("should test more calendar stuff", () => {
      assert.strictEqual(
        eval(compile("吾嘗觀「「曆法」」之書。方悟「言彼之日時」之義。施「言彼之日時」於四千七百一十四。書之。", compile_options)),
        "西元一九六九年己酉年十一月二十三日庚辰日戌正一刻三分三十四秒"
      );
    });
  });
});

You're more familiar with the testing part, so please let me know if this approach is good :)

[antfu]

@LingDong- Just think about the same thing! Stdlib definitely needs some better tests. Though I am a little bit too busy recently to work on this.

For this approach we can write a simple utils to wrap the compile options and other stuff. Then we can focus on input/output when writing tests. I will make a PR for this later.

[LingDong-]

@antfu Sounds great, thanks! No hurry ;) I can look into this too.