Comments on: Unit Testing Expression Tree Equality http://quickduck.com/blog/2009/08/25/unit-testing-expression-tree-equality/ Straight from the mind of geniuseseses.... Fri, 06 Aug 2010 07:40:27 -0700 hourly 1 http://wordpress.org/?v=3.0.1 By: Drew http://quickduck.com/blog/2009/08/25/unit-testing-expression-tree-equality/comment-page-1/#comment-11909 Drew Thu, 24 Dec 2009 04:10:22 +0000 http://quickduck.com/blog/?p=131#comment-11909 Ian, That sounds like a great idea. We could feature it in an upcoming post if you like? Ian,
That sounds like a great idea. We could feature it in an upcoming post if you like?

]]> By: Ian http://quickduck.com/blog/2009/08/25/unit-testing-expression-tree-equality/comment-page-1/#comment-11688 Ian Sat, 21 Nov 2009 12:11:10 +0000 http://quickduck.com/blog/?p=131#comment-11688 Hi, It seems like compiling the expression and invoking it with an arbitrary value is a really bad way of unit testing expressions, because the only way to be certain that the expressions are for all intents and purposes equal is to perform this comparison with every possible value. That's not too big a task when the input is a single Int32, but considering System.Func can accept up to 5 input parameters even testing with ints will get unrealistic very quickly. It seems like the best way to test equivalence of expressions is to do as you suggest and compare each part of the tree using an expression visitor. This isn't very hard to do. In fact, I've written an expression visitor that does exactly this in less than 200 lines of code, and most of those lines are very mundane. You're welcome to it if you'd like. Thanks, Ian Hi,

It seems like compiling the expression and invoking it with an arbitrary value is a really bad way of unit testing expressions, because the only way to be certain that the expressions are for all intents and purposes equal is to perform this comparison with every possible value. That’s not too big a task when the input is a single Int32, but considering System.Func can accept up to 5 input parameters even testing with ints will get unrealistic very quickly.

It seems like the best way to test equivalence of expressions is to do as you suggest and compare each part of the tree using an expression visitor. This isn’t very hard to do. In fact, I’ve written an expression visitor that does exactly this in less than 200 lines of code, and most of those lines are very mundane. You’re welcome to it if you’d like.

Thanks,
Ian

]]> By: Ben http://quickduck.com/blog/2009/08/25/unit-testing-expression-tree-equality/comment-page-1/#comment-11424 Ben Fri, 13 Nov 2009 00:19:24 +0000 http://quickduck.com/blog/?p=131#comment-11424 You're a douche ;) The snippet: "So if you have two expressions that are syntactically the same but not the same reference the easiest way to ensure they are the same is to compile the expression and invoke it comparing the resultant value." Says exactly that. *jerk* You’re a douche ;)

The snippet:

“So if you have two expressions that are syntactically the same but not the same reference the easiest way to ensure they are the same is to compile the expression and invoke it comparing the resultant value.”

Says exactly that.

*jerk*

]]> By: Robert http://quickduck.com/blog/2009/08/25/unit-testing-expression-tree-equality/comment-page-1/#comment-11373 Robert Wed, 11 Nov 2009 06:06:57 +0000 http://quickduck.com/blog/?p=131#comment-11373 Correct me if im wrong. (anyone please) but this will only actually test that the final output value of the Actual Expression is the same as the final output value of the Expected Expression, given some dummy input value. It wont actually test expression equality since some simple logic would show that you can have two completely different expressions return the same result for any given input. Correct me if im wrong. (anyone please) but this will only actually test that the final output value of the Actual Expression is the same as the final output value of the Expected Expression, given some dummy input value. It wont actually test expression equality since some simple logic would show that you can have two completely different expressions return the same result for any given input.

]]>