Comments on: To Clone or not to Clone http://www.iam.unibe.ch/~akuhn/blog/2009/to-clone-or-not-to-clone/ Random notes on software, programming and languages. Thu, 24 May 2012 10:42:17 +0000 http://wordpress.org/?v=2.7 hourly 1 By: akuhn http://www.iam.unibe.ch/~akuhn/blog/2009/to-clone-or-not-to-clone/comment-page-1/#comment-3160 akuhn Thu, 27 Aug 2009 09:31:03 +0000 http://www.iam.unibe.ch/~akuhn/blog/?p=299#comment-3160 Good point, I like to idea of a dynamic default. This could even be done per node: if there is only one consumer RERUN should be the default. In general, if there are n consumer, only n-1 results need to be cloned thus we could omit the clone for the last consumer. Alas, if a grandchild-consumer triggers a rerun of a child-consumer, this child consumes its input twice or more. I am still trying to figure out the best strategy to omit unnecessary clones. We are also working on a solution to dispose cached return values after their last use to reduce the memory footprint of running large test suites. Good point, I like to idea of a dynamic default. This could even be done per node: if there is only one consumer RERUN should be the default.

In general, if there are n consumer, only n-1 results need to be cloned thus we could omit the clone for the last consumer. Alas, if a grandchild-consumer triggers a rerun of a child-consumer, this child consumes its input twice or more. I am still trying to figure out the best strategy to omit unnecessary clones. We are also working on a solution to dispose cached return values after their last use to reduce the memory footprint of running large test suites.

]]> By: Markus http://www.iam.unibe.ch/~akuhn/blog/2009/to-clone-or-not-to-clone/comment-page-1/#comment-3159 Markus Wed, 26 Aug 2009 19:44:50 +0000 http://www.iam.unibe.ch/~akuhn/blog/?p=299#comment-3159 "InjectionPolicy.RERUN reruns all providers whenever injection values are required. This strategy is most stable, however you lose the benefit of faster test execution." At least the "stack-creating"-provider is only run two times in the example, instead of three times, as it would be the case if creating the stack would be a real test and not a mere setup. So do you really "lose the benefit of faster test execution."? A bit yes, but can you estimate the average number of reuses of provider test cases? Say if test cases would be reused only once on average, the Rerun-policy would make a decent default. In general it is good to have those three options of course you came up with. Keep up that great work including this blog Cheers Markus “InjectionPolicy.RERUN reruns all providers whenever injection values are required. This strategy is most stable, however you lose the benefit of faster test execution.” At least the “stack-creating”-provider is only run two times in the example, instead of three times, as it would be the case if creating the stack would be a real test and not a mere setup.
So do you really “lose the benefit of faster test execution.”? A bit yes, but can you estimate the average number of reuses of provider test cases? Say if test cases would be reused only once on average, the Rerun-policy would make a decent default.

In general it is good to have those three options of course you came up with.
Keep up that great work including this blog

Cheers

Markus

]]>