Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Test: add tests for compiler #721
globalize-compiler complains about missing peer dependencies. One is globalize, the other two are cldr-data and iana-tz-data.
Globalize is obviously available, cldr-data is also available from bower. So it still works.
iana-tz-data was recently added to globalize-compiler, but it's not in globalize.js's master, only in the 1.3.0-alpha.3 tag. I think you might have forgotten to push to master.
Hi @nkovacs, this is a great addition, thank you!
Having said that, there is a detail I would prefer done differently: the tests should be explicit, not dynamically generated. Currently, the
Please, could you update that? Globalize compiler tests could be used as baseline (note its functional tests) https://github.com/globalizejs/globalize-compiler
The problem is that when the runtime bundle is compiled, it needs to be executed with the exact same formatters. That's why I need the separate case files.
The only thing I can think of here is to put the formatter part into a function, and use function.toString() to generate the testfile.
I prefer the current code because you have the different test cases clearly listed in the testcase files without too much overhead.
The compiled code can be generated before the tests are executed, which is the approach taken in globalize-compiler tests: https://github.com/globalizejs/globalize-compiler
In globalize-compiler the fixtures are generated before the tests run. This means that technically you are not actually testing the compiler, you're just testing the runtime code, and assuming that the bundle is always generated correctly. You don't get proper code coverage, you can't use watch mode, and you can't run mocha directly either.
In globalize-compiler's functional tests, the only reason this test works, for example, is that the fixture contains a completely unrelated Globalize.formatDate call. This dependency is not obvious and easy to break, especially since the functional tests use the fixtures of the unit tests, it's not obvious that those fixtures are needed by the functional tests.
The tests in globalize-compiler also validate the exact output. The tests here do not. They only check that the testcase has the exact same output when running with the runtime bundle as when running with the full fat globalize.js + cldr data, because that's what you care about when testing the compiler. You already have tests that verify that the individual formatters do what they're supposed to do, there's no need to check that here too, and it makes maintenance simpler.
While I would prefer to be able to have explicit