Comments for Talking About Code http://www.ambersolutions.com.au/dburstin A journey of learning, trying and learning some more Wed, 05 Feb 2014 23:40:19 +0000 hourly 1 https://wordpress.org/?v=4.0.38 Comment on Growing IDisposable Guided By Tests by admin http://www.ambersolutions.com.au/dburstin/index.php/2014/02/03/growing-idisposable-guided-by-tests/#comment-5 Wed, 05 Feb 2014 23:40:19 +0000 http://www.ambersolutions.com.au/dburstin/?p=74#comment-5 Hi J.B. Thanks for the reply.

I thought about doing something like that but it just seems to shift the problem (if I am understanding you correctly). While this would allow me to test that SuppressFinalizeOnThis() was called, the thing I really need to test is that GC.SuppressFinalize(this) was called. I would still need to confirm that this call was being made inside SuppressFinalizeOnThis(). I don’t know how to do that except by visual inspection, which gets me back to the original problem.

]]> Comment on Growing IDisposable Guided By Tests by J. B. Rainsberger http://www.ambersolutions.com.au/dburstin/index.php/2014/02/03/growing-idisposable-guided-by-tests/#comment-4 Wed, 05 Feb 2014 22:04:29 +0000 http://www.ambersolutions.com.au/dburstin/?p=74#comment-4 Regarding test 3, you could check your call to GC.SuppressFinalize(this) by introducing a non-public instance method SuppressFinalizeOnThis() which delegates to GC. This then acts like a collaborator that, in some languages, you might pull out into a mixin/trait.

I don’t think I’d suggest it until you had reason to believe that you weren’t calling GC.SuppressFinalize() correctly.

]]>