You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many languages that support Mustache (especially non-scripting languages like C++, Java, C#, etc) are not currently supported by the lambda test cases. It is also non-trivial to write new test cases in the current form.
It occurs to me that the lambda test cases could be written in a language-independent way. Naively, one might think that a dictionary for each lambda of input-output pairs would suffice to define the lambdas for test cases purposes (similar to how partial data is handled in the partial test cases.
However, given our issue #30 discussion, something like an (ordered) list of triples of (expected lambda called, output, expected input args) might be closer to the appropriate structure. The right structure would also address the question of how best to test things like lambda evaluation order and non-caching independent of each other.
Implementers would need to change or add to their test harnesses code (in their respective languages) to create the lambdas from that data. The lambdas would need to include assertions that the expected input is correct. Assertions should probably also be made about the overall (global, across-lambda) evaluation order.
The text was updated successfully, but these errors were encountered:
Many languages that support Mustache (especially non-scripting languages like C++, Java, C#, etc) are not currently supported by the lambda test cases. It is also non-trivial to write new test cases in the current form.
It occurs to me that the lambda test cases could be written in a language-independent way. Naively, one might think that a dictionary for each lambda of input-output pairs would suffice to define the lambdas for test cases purposes (similar to how partial data is handled in the partial test cases.
However, given our issue #30 discussion, something like an (ordered) list of triples of (expected lambda called, output, expected input args) might be closer to the appropriate structure. The right structure would also address the question of how best to test things like lambda evaluation order and non-caching independent of each other.
Implementers would need to change or add to their test harnesses code (in their respective languages) to create the lambdas from that data. The lambdas would need to include assertions that the expected input is correct. Assertions should probably also be made about the overall (global, across-lambda) evaluation order.
The text was updated successfully, but these errors were encountered: