Add tests from cel-go checker

[jafaircl]

The existing type_deduction tests in the conformance suite are good for end to end testing. But, to properly develop the checker one expression type at a time, we need more granular tests. This PR adds the checker tests from cel-go in a similar way to the parsing suite.

[srikrsna-buf]

Aren't we doing end to end testing with these as well? The go tests match the ast. This allows them to test types for every part of the expression. But we are only matching the output. How is this different from the conformance suite?

[jafaircl]

Unless I am missing something, the conformance suite does not have the granularity needed to test individual expression types. Since you wanted the checker broken up into so many PRs, it can't reasonably be tested incrementally with the conformance suite tests.

[srikrsna-buf]

Let me clarify with an example from the go test suite:

	in:      `1 + 2`,
	out:     `_+_(1~int, 2~int)~int^add_int64`,
	outType: types.IntType,
	env:     testEnvs(t)["default"],

In this case, the tests in cel-go are verifying the entire CheckedExpr by using the out value. We are not doing that, and only checking the output type just like the conformance suite. If we are only doing end to end checks, how is this better than the conformance suite?

[jafaircl]

It's not better. The point is that we can use these tests to check individual expression types. If the conformance suite is the only set of tests you're interested in, what's the point of doing this exact same thing for the parser tests? The logic is inconsistent.

[srikrsna-buf]

If the conformance suite is the only set of tests you're interested in

That is not my intention. I was asking a question referring to your original statement that conformance tests are good for e2e tests and this will help develop the checker one expression at a time. I was just pointing out that we are not verifying the result in the same way go is doing.

what's the point of doing this exact same thing for the parser tests? The logic is inconsistent.

In the parser tests, we verify the result like go does by matching the debug string of the output:

cel-es/packages/cel/src/testing.ts

Lines 114 to 120 in 097d5ef

	if (test.ast) {
	const actual = toDebugString(
	parse(test.original.expr),
	KindAdorner.singleton,
	);
	const expected = test.ast;
	assert.deepStrictEqual(actual, expected);

A similar check is missing in this PR.

[jafaircl]

Ok I think I understand what you mean now. I didn't realize you wanted the entire checked ast tested. Take a look at the latest changes and let me know if that's more in line with what you're thinking.

[srikrsna-buf]

LGTM